Patent ID: 12199982

DETAILED DESCRIPTION

The illustrative embodiments recognize and take into account one or more different considerations. For example, the illustrative embodiments recognize and take into account that self-service registration systems require a significant amount of a user's time in completing a registration process for registering with a service, such as, for example, a service that provides access to an employee's payroll and benefits information.

The illustrative embodiments further recognize and take into account that self-service registration systems potentially make sensitive user data such as financial information available to would-be hackers to fraudulently misuse.

The illustrative embodiments provide a user self-service registration system that is quick and easy to use for a user and that results in greater success in completing a registration process. The illustrative embodiments also provide a user self-service registration system with increased security as compared to existing systems that minimizes the opportunity for unauthorized access to a user's sensitive information.

With reference now to the figures and, in particular, with reference toFIG.1, an illustration of a diagram of a data processing environment is depicted in accordance with an illustrative embodiment. It should be appreciated thatFIG.1is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the environments in which the different embodiments may be implemented. Many modifications to the depicted environments may be made.

The computer-readable program instructions may also be loaded onto a computer, a programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, a programmable apparatus, or other device to produce a computer implemented process, such that the instructions which execute on the computer, the programmable apparatus, or the other device implement the functions and/or acts specified in the flowchart and/or block diagram block or blocks.

FIG.1depicts a pictorial representation of a network of data processing systems in which illustrative embodiments may be implemented. Network data processing system100is a network of computers in which the illustrative embodiments may be implemented. Network data processing system100contains network102, which is a medium used to provide communications links between various devices and computers connected together within network data processing system100. Network102may include connections, such as wire, wireless communication links, or fiber optic cables.

In the depicted example, server computer104, server computer105, and server computer106connect to network102along with storage unit108. In addition, client computers include client computer110, client computer112, and client computer114. Client computer110, client computer112, and client computer114connect to network102. These connections can be wireless or wired connections depending on the implementation. Client computer110, client computer112, and client computer114may be, for example, personal computers or network computers. In the depicted example, server computer104, server computer105, and/or server computer106provide information, such as boot files, operating system images, and applications to client computer110, client computer112, and client computer114. Client computer110, client computer112, and client computer114are clients to server computer104in this example. Network data processing system100may include additional server computers, client computers, and other devices not shown.

Program code located in network data processing system100may be stored on a computer-recordable storage medium and downloaded to a data processing system or other device for use. For example, the program code may be stored on a computer-recordable storage medium on server computer104and downloaded to client computer110over network102for use on client computer110.

In the depicted example, network data processing system100is the Internet with network102representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers consisting of thousands of commercial, governmental, educational, and other computer systems that route data and messages. Of course, network data processing system100also may be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN).FIG.1is intended as an example, and not as an architectural limitation for the different illustrative embodiments.

The illustration of network data processing system100is not meant to limit the manner in which other illustrative embodiments can be implemented. For example, other client computers may be used in addition to or in place of client computer110, client computer112, and client computer114as depicted inFIG.1. For example, client computer110, client computer112, and client computer114may include a tablet computer, a laptop computer, a bus with a vehicle computer, and other suitable types of clients.

In the illustrative examples, the hardware may take the form of a circuit system, an integrated circuit, an application-specific integrated circuit (ASIC), a programmable logic device, or some other suitable type of hardware configured to perform a number of operations. With a programmable logic device, the device may be configured to perform the number of operations. The device may be reconfigured at a later time or may be permanently configured to perform the number of operations. Programmable logic devices include, for example, a programmable logic array, programmable array logic, a field programmable logic array, a field programmable gate array, and other suitable hardware devices. Additionally, the processes may be implemented in organic components integrated with inorganic components and may be comprised entirely of organic components, excluding a human being. For example, the processes may be implemented as circuits in organic semiconductors.

Turning now toFIG.2, a block diagram of a user self-service registration environment is depicted in accordance with an illustrative embodiment. User self-service registration environment200includes registration system202, user device214used to register with the registration system, trusted partner220, third-party risk analyzer218, and knowledge-based authentication (KBA) database226containing questions and answers to aid in authenticating the user, the questions, and answers obtained from publicly available information. Registration system202may be implemented as, for example, server104inFIG.1. User device214may be implemented as client computer112inFIG.1. Trusted partner220may be implemented as server105inFIG.1and third-party risk analyzer218may be implemented as server106inFIG.1. KBA database226may be implemented as storage108inFIG.1.

Registration system202allows a user to register for a service such as, for example, a payroll and benefits service that allows the user to view data and information related to their salary, insurance benefits, taxes, retirement account, and/or any other of a number of types of information. Registration system202and the service for which access is provided via registration system202may be provided directly by an employer or may be a service provided by a third-party contracting to the employer.

Registration system202includes user registration interface208, encryption/decryption unit210, trusted partner interface212, personal registration code (PRC) generator204, organization registration code (ORC) generator205, user name and password storage211, service user data database213, and a risk analyzer206. Registration system202authenticates the user to verify the user is who they claim to be and creates a user ID and password for the service for which the user is attempting to register upon successful authentication of the user and upon successfully receiving the user data. The user data may include, for example, first and last name, data of birth, a user unique identifier (e.g., a social security number (SSN), a passport number, a state issued driver's license number, other governmental issued identifier, an employer issued employee number, etc.). The user data may also include bank account numbers for direct deposit of the employees pay and retirement account numbers for depositing retirement income into.

User registration interface208is configured to provide an interface through which the user can register with registration system202through user device214. The user device may be any number of devices for communication including a smart phone, a laptop computer, a desktop computer, and a tablet computer. User registration interface208creates prompts for the user to enter various data into user device214. User registration interface208prompts the user to enter a registration code and determines whether the registration code received from the user is a PRC or an ORC. The ORC is generated by ORC generator205and provided to the organization or client of a service provider of the service for which the user is attempting to register. The organization or client provides the ORC to the user. The ORC is an organization wide code that multiple users may use to register for the service. If the organization or client uses a PRC, then the PRC generator204may generate a PRC code and provide it to the user via user secondary channel216such as via e-mailing the PRC to an e-mail address or via texting the code to a phone number known to belong to the user. User secondary channel216is a different channel from the communications channel used by user device214to enter registration information via user registration interface208. User device214typically interacts with user registration interface208via a web based connection. However, although the communication channels may be different, the user may receive the PRC from PRC generator204via user secondary channel216using the same user device214as is used by the user to attempt registration with registration system202. The user may be authenticated by successful use of the PRC.

The user may enter their data directly through user registration interface208using their user device214or alternatively which is described in more detail below with respect toFIG.3, the user may provide authorization for their information to be shared from trusted partner220and be redirected to trusted partner220to login to user login interface222. Upon successful authentication of the user to trusted partner220, trusted partner220may transfer the user data from the trusted partner's user data224to registration system202via trusted partner interface212. The user data is encrypted during transfer and encryption/decryption unit210in registration system202decrypts the encrypted data. More details concerning transfer of user data from the trusted partner in order to populate the user data for the service for which the registration system202is associated is described below with respect toFIG.4. Once the user data is received, whether through entry by the user or through transfer from trusted partner220, the data is stored in service user data database213. User ID and password storage211stores the user login ID (or user name) and password created by the user subject to the rules in the registration system upon successful authentication of the user and successful receipt of the user data. The user ID may be auto-generated or created by the user during the course of the registration process. If the user ID is created by the user, the user ID will be subject to the rules of the registration system. In an embodiment, the user data, user login ID, and user password are encrypted by encryption/decryption unit210before storing in service user data database213.

If the user cannot or does not want to have data transferred from trusted partner220, the registration system can authenticate the user in other ways by either issuing another PRC generated by PRC generator204and sent to the user over user secondary channel216or through successfully answering a query of a KBA question or a series of KBA questions determined from KBA database226. KBA database226may be a third-party database or may be a database controlled by registration system202. KBA database226contains a number of questions and answers specific to the user that are obtained from publicly available sources. In order to prevent fraud and authenticate the user, the registration system may obtain a risk score from third-party risk analyzer218and analyzed by risk analyzer206to determine the risk that the user attempting to register is attempting to do so fraudulently (i.e., that the user is not who they claim to be). For higher risk attempted registrations, the authentication process may be more involved. For lower risk attempted registrations, the authentication process may be less involved. Third-party risk analyzer218may create a risk score based on publicly available information about the user and/or about the location from which the user is attempting to register. The algorithm for determining the risk score is agreed upon by the provider of the registration service and the third-party risk analyzer. The risk score may be compared to a threshold to determine whether the attempted registration is high or low risk. The threshold may be dynamically determined and change over time as more information is obtained about what constitutes high and low risk based on previous registration attempts.

Turning now toFIG.3, a flowchart of an exemplary self-service process for registering a user to a service is depicted in accordance with an illustrative embodiment. Process300may be implemented in user self-service registration environment200. Process300begins with a user entering a registration code (step301) into an interface of a registration system. Next, the registration system determines whether the registration code is an organization registration code (ORC) or a personal registration code (PRC) (step302). The ORC is unique to the client (e.g., an employer utilizing the registration service) but shared across all employees of the client. The PRC is unique for each employee within the client and typically expires after a specified period (e.g., days after being issued). In an embodiment, the PRC registration is more secure and has a higher success rate (i.e., a user successfully registering with a service) than the ORC registration.

If the registration system determines that the registration code is a PRC, then the process proceeds to step303where the user enters data (e.g., user identity number, first name, last name, data of birth, etc.). In an embodiment, the user identity number is a social security number (SSN), but can be any number, such as a state issued driver's license number, a passport number, etc., that uniquely identifies the user. Once the data has been entered at step303, process300proceeds to step304where the user contact information is updated in the registration system database and the user creates a system user identification (i.e., a user name) and a password, after which, process300ends. Although not shown inFIG.3, in some embodiments, a user registering using a PRC may elect to have their data imported from a trusted partner in a manner similar to that described below for user's using an ORC and shown inFIG.3.

If, at step302, the registration system determines that the registration code is an ORC, then process300proceeds to step305where the registration system determines whether the user will perform SSN based identity verification. If, yes, then process300proceeds to step306where the registration service determines whether the user will enter the data manually or whether the data will be imported from other trusted sources. If the data will be imported from trusted sources at step306, then process300continues to step314where the data is imported from a trusted source, after which, process300ends. A trusted source is another entity, such as a bank, an insurance company, a financial institution, or some other entity which the provider of the registration service trusts and with which the user has an account. The user will log into their account with the trusted source and provide authorization for the trusted source to transfer the user's data to the provider of the registration service. The data transferred is encrypted thereby preserving security. Furthermore, the registration process is simplified and the time to register reduced, thereby improving the user experience in registering for the service. More details about importing data from a trusted source are provided inFIG.4and described below.

If, at step306, the user desires to enter their data directly, or if, at step305, the user indicates that SSN based identity verification will not be performed, process300proceeds to step307where the user enters the user data and the registration system performs additional security checks to prevent fraudulent access to the data provided by the entity with which the user is attempting to register. The additional security checks may include requesting additional information from the user. The user may select manual data entry at step306for a variety of reasons. For example, the user may not have an account with an entity which is a trusted partner with the provider of the registration service. As another example, the user may not wish to allow the provider of the registration service to access information from one of the user's other accounts. However, regardless of the reason, if the user selects the choice of entering the data manually at step306, the process proceeds to step307.

Next, the registration service determines whether SSN based identity verification will be conducted (step308). If, at step308, no SSN based identity verification will occur, then process300proceeds to step304where the user contact information is updated and a user ID and password are created. If, at step308, SSN based identity verification will be performed, then process300proceeds to step309where user personal identifying information (PII) is passed to a risk evaluation analyzer for risk analysis. In an embodiment, the risk analysis is an artificial intelligence (AI) based risk analysis and the criteria for determining high and low risk may be updated occasionally to reflect better information. In an embodiment, the risk evaluation analyzer is a third-party risk analyzer and that PII passed to the risk evaluation analyzer contains only non-sensitive PII. Examples of non-sensitive PII include a user's first and last name, the user's data of birth, the user's e-mail address, and the user's telephone number. This information is generally publicly available and is usually insufficient for someone to use to steal a user's identity or to access sensitive information like the user's bank account, etc. Examples of sensitive PII include the user's social security number (SSN), the user's driver's license number, the user's passport number, etc.

Next, the risk analyzer processes the risk score and determines whether there is a high or low risk as to whether the person attempting to register is not the person corresponding to the SSN or other sensitive PII (step310). The score is determined by the third-party according to data analysis and policy agreed upon by both the third-party and the registration system. The threshold for determining whether the risk score corresponds to a high risk or a low risk is dynamically determined and can be revised periodically to reflect updated information about the risks associated with various factors. Factors used in determining the risk may include the location of the attempt to register, the known location of the user's residence, the known location of the user's employer, other user specific data, etc. For example, in some embodiments, an attempt to register from a location that is in a vastly different location from the known residence of the user, such as in a different country, may be a factor that increases the risk score as it is more likely that the person attempting to register is not the user corresponding to the SSN or other sensitive PII. In an embodiment, the location of the registration attempt may be determined from the IP address of the device the person is using to register. In an embodiment, a higher risk score indicates a higher risk and determining whether there is a high risk of identity fraud is based on whether the risk score exceeds a threshold. Scores below the threshold would be considered low risk in this embodiment. In other embodiments, a lower risk score indicates a higher risk and determining whether there is a high risk of identity fraud is based on whether the risk score is below a threshold. In various embodiments, the risk scores that are equal to the threshold value may be considered high risk or low risk, depending on implementation. The threshold score for determining whether the attempted user registration is high or low risk may change over time based on additional data.

If the risk score indicates a low risk of fraud (i.e., a low risk that the person attempting to register is not the user corresponding to the user identifier (e.g., SSN)), then process300continues to step304, after which, process300ends. If the risk score indicates there is a high risk that the person attempting to register is not the user corresponding to the sensitive PII, then process300proceeds to step311where the registration system determines whether the user will register on-the-fly using a personal registration code (PRC) or using knowledge based authentication (KBA).

If, at step311, the user elects on-the-fly PRC, then process300proceeds to step312where the registration system generates a code and sends it to the user via e-mail, telephone, or other channels known to belong to the user. Upon successful entry of the code into the registration system by the user, process300proceeds to step304where the user contact information is updated and a user ID and password are created for the user, after which, process300ends.

If, at step311, the user elects KBA for further authenticating the user, process300proceeds to step313where KBA questions are generated from public records and presented to the user. Upon successfully answering at least one KBA question, the process proceeds to step304where the user contact information is updated and a user ID and password are created for the user, after which, the process300ends. In some embodiments, the user must successfully answer more than one KBA question, such as, for example, at least three KBA questions.

If, at step312, step313, or other places within the process300, the user is unsuccessful in providing the PRC code, appropriate answers to the KBA questions, or successfully answering other questions, process300may end. If the user wishes to still keep trying to register, the user may need to start over at step301. In order to further prevent fraud, in some embodiments, the user is not allowed to start over until a client administrator or a registration service administrator resets the registration system for this user. The process of ending the registration process and for locking out the user may be utilized at any point in process300in which the user fails to successfully provide answers to the questions presented to them. In various embodiments, the user may be provided with a limited number of tries to successfully answer a question before being locked out.

Turning now toFIG.4, a flowchart of an exemplary self-service process for importing user data from a trusted partner to a service is depicted in accordance with an illustrative embodiment. Process400may be implemented in user self-service registration environment200inFIG.2. Process400may be implemented at step314inFIG.3.

Process400begins with a user choosing to log into a partner site in order to provide the information to the registration service necessary to complete the registration (step401). Next, the user lands on the trusted partner web page and the registration system passes a unique identifier for authorization (step402). Next, the user authenticates their account to the trusted partner and consents to data exchange between the trusted partner and the registration service (step403). The registration system then performs a backend call to the trusted partner to obtain a token (also referred to as an access token) and to retrieve user data (step404). The token is used to determine that the registration system is authorized to exchange data with the trusted partner. The registration system then receives encrypted data from the trusted partner and decrypts the encrypted data to obtain the user data (step405). The registration system retrieves the SSN (or other unique identifier (e.g., driver's license number, passport number, etc.) of the user based on a lookup in a registry of the registration system (step406). Next, the registration system obtains a unique “salt” value from the trusted partner for this identity and the hash function used by the trusted partner. Then the registration system salts and hashes the SSN and user data (step407). A salt value is a random data that is used as an additional input to a one-way hash function. Salting and hashing data are well known to those of ordinary skill in the art. The registration system then validates whether the user identifier (e.g., SSN) in the registration system's records match with that on record with the partner (step408). In an embodiment, the registration system validates the SSN by sending the salted and hashed user identifier (e.g., SSN) to the trusted partner. The trusted partner matches whether the user identifier from the registration system matches with what they have on their record by comparing the hash values of the user identifier. The trusted partner then returns a match or no match status to the registration system. In an alternate embodiment, the registration system validates the user by comparing the user identifier (e.g., SSN) from the registration system's records with the encrypted value of the SSN received from the trusted partner (after decrypting the encrypted value) to determine whether the two values match. Upon successfully receiving validation of the SSN, the registration system pre-populates the user data with the data received from the trusted partner (step409). Finally, the content information is updated the user ID and password are created (step410), after which, the process400ends. Because the user is spared the time and trouble of entering their data manually due to the importing of their data from the trusted partner, the user can complete the registration process quicker, and in some embodiments, at least twice as fast as possible with manual data entry. Furthermore, because the partner providing the data is a trusted partner, meaning that the registration service trusts that the partner vets the data as well or better than the registration system does, the registration system has assurance that the data is accurate. Furthermore, the transfer of data is performed via encryption and with the use of tokens, thereby ensuring that the registration process has bank grade security.

Turning now toFIG.5, an illustration of a block diagram of a data processing system is depicted in accordance with an illustrative embodiment. Data processing system500may be used to implement one or more computers, servers104,105,106and client computer systems110,112,114inFIG.1. In this illustrative example, data processing system500includes communications framework502, which provides communications between processor unit504, memory506, persistent storage508, communications unit510, input/output unit512, and display514. In this example, communications framework502may take the form of a bus system.

Processor unit504serves to execute instructions for software that may be loaded into memory506. Processor unit504may be a number of processors, a multi-processor core, or some other type of processor, depending on the particular implementation. In an embodiment, processor unit504comprises one or more conventional general purpose central processing units (CPUs). In an alternate embodiment, processor unit504comprises one or more graphical processing units (GPUs).

Memory506and persistent storage508are examples of storage devices516. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, at least one of data, program code in functional form, or other suitable information either on a temporary basis, a permanent basis, or both on a temporary basis and a permanent basis. Storage devices516may also be referred to as computer-readable storage devices in these illustrative examples. Memory516, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage508may take various forms, depending on the particular implementation.

For example, persistent storage508may contain one or more components or devices. For example, persistent storage508may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage508also may be removable. For example, a removable hard drive may be used for persistent storage508. Communications unit510, in these illustrative examples, provides for communications with other data processing systems or devices. In these illustrative examples, communications unit510is a network interface card.

Input/output unit512allows for input and output of data with other devices that may be connected to data processing system500. For example, input/output unit512may provide a connection for user input through at least one of a keyboard, a mouse, or some other suitable input device. Further, input/output unit512may send output to a printer. Display514provides a mechanism to display information to a user.

Instructions for at least one of the operating system, applications, or programs may be located in storage devices516, which are in communication with processor unit504through communications framework502. The processes of the different embodiments may be performed by processor unit504using computer-implemented instructions, which may be located in a memory, such as memory506.

These instructions are referred to as program code, computer-usable program code, or computer-readable program code that may be read and executed by a processor in processor unit504. The program code in the different embodiments may be embodied on different physical or computer-readable storage media, such as memory506or persistent storage508.

Program code518is located in a functional form on computer-readable media520that is selectively removable and may be loaded onto or transferred to data processing system500for execution by processor unit504. Program code518and computer-readable media520form computer program product522in these illustrative examples. In one example, computer-readable media520may be computer-readable storage media524or computer-readable signal media526.

In these illustrative examples, computer-readable storage media524is a physical or tangible storage device used to store program code518rather than a medium that propagates or transmits program code518. Alternatively, program code518may be transferred to data processing system500using computer-readable signal media526.

Computer-readable signal media526may be, for example, a propagated data signal containing program code518. For example, computer-readable signal media526may be at least one of an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals may be transmitted over at least one of communications links, such as wireless communications links, optical fiber cable, coaxial cable, a wire, or any other suitable type of communications link.

The different components illustrated for data processing system500are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a data processing system including components in addition to or in place of those illustrated for data processing system500. Other components shown inFIG.5can be varied from the illustrative examples shown. The different embodiments may be implemented using any hardware device or system capable of running program code518.

As used herein, the phrase “a number” means one or more. The phrase “at least one of”, when used with a list of items, means different combinations of one or more of the listed items may be used, and only one of each item in the list may be needed. In other words, “at least one of” means any combination of items and number of items may be used from the list, but not all of the items in the list are required. The item may be a particular object, a thing, or a category.

For example, without limitation, “at least one of item A, item B, or item C” may include item A, item A and item B, or item C. This example also may include item A, item B, and item C or item B and item C. Of course, any combinations of these items may be present. In some illustrative examples, “at least one of” may be, for example, without limitation, two of item A; one of item B; and ten of item C; four of item B and seven of item C; or other suitable combinations.

The flowcharts and block diagrams in the different depicted embodiments illustrate the architecture, functionality, and operation of some possible implementations of apparatuses and methods in an illustrative embodiment. In this regard, each block in the flowcharts or block diagrams may represent at least one of a module, a segment, a function, or a portion of an operation or step. For example, one or more of the blocks may be implemented as program code.

In some alternative implementations of an illustrative embodiment, the function or functions noted in the blocks may occur out of the order noted in the figures. For example, in some cases, two blocks shown in succession may be performed substantially concurrently, or the blocks may sometimes be performed in the reverse order, depending upon the functionality involved. Also, other blocks may be added in addition to the illustrated blocks in a flowchart or block diagram.

The description of the different illustrative embodiments has been presented for purposes of illustration and description and is not intended to be exhaustive or limited to the embodiments in the form disclosed. The different illustrative examples describe components that perform actions or operations. In an illustrative embodiment, a component may be configured to perform the action or operation described. For example, the component may have a configuration or design for a structure that provides the component an ability to perform the action or operation that is described in the illustrative examples as being performed by the component. Many modifications and variations will be apparent to those of ordinary skill in the art. Further, different illustrative embodiments may provide different features as compared to other desirable embodiments. The embodiment or embodiments selected are chosen and described in order to best explain the principles of the embodiments, the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.