Patent Publication Number: US-10791104-B2

Title: Systems and methods for authenticating users of a computer system

Description:
RELATED APPLICATIONS 
     This application, U.S. patent application Ser. No. 15/358,052 filed Nov. 21, 2016, claims benefit of U.S. Provisional Application Ser. No. 62/258,006 filed Nov. 20, 2015, the contents of which are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     The present invention relates to systems and methods for authenticating users of a website and, more specifically, to such systems and methods that increase security while maintaining usability. 
     BACKGROUND 
     Websites often maintain specific information for a particular user in a user account specific to that particular user. Because a user account may contain sensitive information, websites that maintain user accounts are typically configured to request the verification that a user attempting to obtain access to a particular user account is the particular user associated with that particular user account. Perhaps the most common method of verifying that access to a particular user account is restricted to the particular user associated with that account is to require the entry of a user name and password created by the particular user. For a variety of reasons, user names and passwords are conventionally considered not to an ideal method of restricting access to a user account. 
     The need thus exists for systems and methods of restricting access to user accounts in addition to or instead of the entry of a user name and password. 
     SUMMARY 
     The present invention may be embodied as an authentication system for allowing access to a user account server comprising at least one access device and at least one verification server. The at least one access device is capable of operatively connecting to the user account server, where the at least one access device comprises a touch screen for allowing entry of session signatures. The at least one verification server capable of comparing session signatures to reference signatures. The at least one user establishes a user reference signature that is stored on the at least one verification server. The at least one user operates the at least one access device to enter a user session signature. The at least one access device transmits the user session signature to the at least one verification server. The at least one verification server allows the at least one user to connect to the user account server based on a comparison of the user session signature with the user reference signature. 
     The present invention may also be embodied as a method of allowing access to a user account server comprising the following steps. At least one access device is operatively connected to the user account server, where the at least one access device comprises a touch screen for allowing entry of session signatures. At least one verification server capable of comparing session signatures to reference signatures is provided. A user reference signature is stored on the at least one verification server. The at least one access device is operated to enter a user session signature. The at least one access device is operated to transmit the user session signature to the at least one verification server. The at least one verification server is operated to allow the at least one user to connect to the user account server based on a comparison of the user session signature with the user reference signature. 
     The present invention may also be embodied as an authentication system for allowing access to a controlled data stored on a user account server comprising at least one access device and at least one verification server. The at least one access device is capable of operatively connecting to the user account server, where the at least one access device comprises a touch screen for allowing entry of session signatures. The at least one verification server is capable of comparing session signatures to reference signatures. The at least one user establishes a user reference signature that is stored on the at least one verification server. The at least one user operates the at least one access device to enter a user session signature. The at least one access device transmits the user session signature to the at least one verification server. The at least one verification server allows the at least one user to access the controlled data on the user account server based on a comparison of the user session signature with the user reference signature. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a generic block diagram of a verification system constructed in accordance with, and embodying, the principles of the present invention; 
         FIG. 2  is a screen shot of a display generated by an access device in a pre-log-in mode of a generic example of the present invention; 
         FIG. 3  is a screen shot of a display generated by the access device in a log-in mode in the generic example; 
         FIG. 4  is a screen shot of a display generated by a verification device in a pre-scan mode in the generic example; 
         FIG. 5  is a screen shot of a display generated by the verification device in a scan mode in the generic example; 
         FIG. 6  is a screen shot of a display generated by the verification device in a pre-authentication mode in the generic example; 
         FIG. 7  is a screen shot of a display generated by the verification device in an authentication mode in the generic example; 
         FIG. 8  is a screen shot of a display generated by the access device in a signed in or logged in mode in the generic example; 
         FIG. 9  is a block diagram illustrating a loan verification system of the present invention; 
         FIG. 10  is a screen shot of a display generated by an applicant access device during the loan processing example of the present invention, the display displaying a digital loan document; 
         FIG. 11  is a screen shot of a display generated by a loan officer access device during a loan processing example of the present invention, the display displaying a document approval request form; 
         FIG. 12  is a screen shot of a display generated by a manager access device during the loan processing example of the present invention, the display displaying a list of alerts associated with a particular loan manager; 
         FIG. 13  is a screen shot of a display generated by the manager access device during the loan processing example of the present invention, the display displaying a selected loan application for approval; 
         FIG. 14  is a screen shot of a display generated by the manager access device during the loan processing example of the present invention, the display displaying the process of interacting with the manager access device to enter an Asignio™ signature; 
         FIG. 15  is a screen shot of a display generated by the applicant access device during the loan processing example of the present invention, the display displaying a list of alerts associated with customer; 
         FIG. 16  is a screen shot of a display generated by the applicant access device during the loan processing example of the present invention, the display displaying a selected loan application for approval; 
         FIG. 17  is a screen shot of a display generated by the applicant access device during the loan processing example of the present invention, the display displaying the process of interacting with the applicant access device to enter an Asignio™ signature; 
         FIG. 18  is a block diagram illustrating a medical prescription approval system of the present invention; 
         FIG. 19  is a screen shot of a display generated by a requestor access device during the prescription processing example of the present invention, the display displaying a digital prescription request form; 
         FIG. 20  is a screen shot of a display generated by medical provider access device during the prescription processing example of the present invention, the display displaying a list of alerts; 
         FIG. 21  is a screen shot of a display generated by a medical provider access device during the prescription processing example of the present invention, the display displaying the process of interacting with the medical provider access device to enter an Asignio™ signature; 
         FIG. 22  is a screen shot of a display generated by a medical provider access device during the prescription processing example of the present invention, the display displaying a list of prescription requests awaiting approval; 
         FIG. 23  is a screen shot of a display generated by a medical provider access device during the prescription processing example of the present invention, the display displaying the details of a selected prescription request awaiting approval; 
         FIG. 24  is a screen shot of a display generated by a medical provider access device during the prescription processing example of the present invention, the display displaying the process of interacting with the medical access device to enter an Asignio™ signature; 
         FIG. 25  is a screen shot of a display generated by the requestor access device during the prescription processing example of the present invention, the display displaying a list of requested prescriptions and also the authorization status of each requested prescription; 
         FIG. 26  illustrates the entry of a signature into a customer mobile device using a touch screen thereof as part of the step of validating a transaction; 
         FIG. 27  is a flow chart illustrating the step of verifying the customer&#39;s signature when performing the step of validating a transaction as described above with respect to  FIG. 1  or as used as part of the example loan processing system of  FIG. 9  and the prescription processing system of  FIG. 18 ; and 
         FIGS. 28A-28D  illustrate the process of establishing a reference signature for use in the example validation step depicted in  FIG. 27 . 
     
    
    
     DETAILED DESCRIPTION 
     The present invention may be embodied in a number of different forms, and several examples of authentication systems and methods constructed in accordance with the principles of the present invention will be described in detail below. 
     I. Website Log-In Example 
     The present invention may be embodied as a verification system  20  that provides the ability to login and/or authenticate for an app or website using a host device. The example verification system  20  comprises at least one primary access device  22 , at least one verification access device  24 , a remote user account server  26  associated with the user account to be accessed, and a verification server  28 . In this example, the primary access device  22  is a desktop computer without a touch screen. The example user account server  26  is a combination of computer hardware and software forming an online service such as a shopping website, bank website, government website, or other service defining user accounts and containing data the access to which is controlled (e.g., controlled data). The example verification access device  22  is a computing device having a touch screen. The example verification server  28  is a combination of computer hardware and software forming an online service capable of storing data and performing a compare operation as will be described below. 
     While the verification access device  24  and verification server  28  are depicted separately in  FIG. 1 , these services may be performed on a single piece of hardware. For example, the verification access device  24  may contain software forming the verification server  28 . As another alternative, more than one verification server  28  may be provided. 
     The website log-in verification process works generally as follows.
         1. A web page served by a client maintaining a client user account server is opened using the primary access device  22 . The web page includes a verification server plug-in control. As shown in  FIG. 2 , the verification server plug-in control displays one or more buttons  30  in a display area on the primary access device  22 . When the button  30  is clicked, a process associated with either screen element calls the verification server  28  if the verification server  28  is installed on the primary access device  22 . The screen element process requests a unique login code image  32  from the verification server  28  and displays this as a code image such as a QR code on the web page as shown in  FIG. 3 . The code image  32  may be any graphic element recognizable using image analysis software. While such image analysis software is widely available for recognizing QR codes, other images may be used to establish a link between the primary access device  22  and the verification access device  24 . For example, a photograph and facial recognition software may be used to establish this link. A pattern and pattern matching software may also be used.   2. Accordingly, after the appropriate button is activated by, for example, touching or clicking, a code image  32  such as a QR code is thus displayed on the web page as shown in  FIG. 3 . The code image is associated with a session ID. Typically, the session ID is associated with a time period during which the authentication process must be completed.   3. The user&#39;s mobile verification access device  24 , running verification device software, is used to scan the code image  32  as shown in  FIGS. 4 and 5 . A scan button  40  is touched, and a scan  42  of the code image  4322  is displayed on the verification access device  24  while the code contained in the code image  32  is verified by the verification server  28 . After the code image  32  has been scanned, the user&#39;s name is confirmed in a text box  44  as shown in  FIG. 6 .   4. The user next authenticates by “signing” on the mobile verification access device  24  as shown at  46  in  FIG. 7 . The mobile verification access device  24  and/or verification server  28  perform calculations to match a user session signature against stored “master” or user reference signature, thereby verifying the identity of the user.   5. If user&#39;s session signature passes, the verification server  28  returns a login token to the web page on the primary access device  22  and to the client user account server  26 .   6. The verification server  28  passes token back up to client user account server  26 .   7. The client user account server  26  calls the verification server  28  with a login token to get login credentials.   8. The verification server  28  returns login credentials to the user account server  26 .   9. The client user account server  26  validates the user, and the user is logged in to the web page displayed on the primary access device  22  as shown at  50  in  FIG. 8 .
 
In the context of logging into an online service formed by the remote user account server  26 , the login process may be performed after visiting the site. For example, for online shopping, the user may be encouraged to shop and fill an online shopping cart and log in only at check out. However, in the case of online banking, the user will likely be required to log in before accessing any confidential information.
       

     II. Financing Example 
       FIG. 9  illustrates a loan processing system  120  employing the verification systems and methods of the present invention. The example loan processing system  120  incorporates a communications system  122  such as the Internet and comprises a loan application server  130 , a verification server  132 , an applicant access device  134 , a loan officer access device  136 , and a manager access device  138 . 
     In the example loan processing system  120 , the loan application server  130  is a combination of computer hardware and software forming an online service capable of storing and allowing access to the data required to process loan applications and generating reports based on such data. The example verification server  132  is a combination of hardware and software capable of storing data and performing a compare operation as will be described below. The example applicant access device  134  is a tablet such as an iPad, while the loan officer access device  136  and manager access device  138  are smart phones such as an iPhone. However, a typical user may have multiple access devices, and different access devices may be used at different points in the process described herein. 
     As an alternative to using access devices  134 ,  136 , and  138  separate from the verification server  132 , the functions of the verification server  132  may be performed on any one or all of the access devices  134 ,  136 , and  138 . As another alternative, more than one verification server  132  may be provided. 
     While verification server  132  and access devices  134 ,  136 , and  138  are depicted separately in  FIG. 9 , these verification services and access services may be performed on a single piece of hardware. For example, the manager access device  138  may contain software forming the verification server  132 . 
     Initially, a customer meets with a loan officer to finalize details of a loan application. As shown in  FIG. 10 , the loan application may be represented as a loan document  140  displayed on the applicant access device  134 . The loan application server  130  will also maintain user accounts associated with the applicant operating the applicant access device  134 , the loan officer operating the loan officer access device  136 , and the manager operating the manager access device  138 . The loan document  140  will also be associated with user accounts. The loan document  140  represents controlled data stored by the loan application server  130 , and each such loan document will be associated with a unit set of user accounts. 
     The verification server  132  will maintain user accounts associated with the applicant operating the applicant access device  134 , the loan officer operating the loan officer access device  136 , and the manager operating the manager access device  138 . The user accounts stored by the verification server  132  will further contain a reference signature created by each user. 
     Next as shown in  FIG. 11 , a loan officer uses the loan officer access device  136  to submit a loan approval request  142  so that the loan manager can review and approve the loan. As shown in  FIG. 12 , the loan manager receives an alert on the manager access device  138  indicating, among other action items, that the loan application is awaiting review. Alerts  150  are viewed in this example by comparing a session signature entered by the manager with a pre-approved reference signature stored in the verification server  132 . 
     At this point, the loan manager, from the list of displayed alerts displayed on the manager access device  138  as depicted in  FIG. 12 , taps the alert associated with the loan application to be approved, authenticates using the verification server  132 , and then reviews the loan application displayed on the manager access device as shown in  FIG. 13 . In particular, the loan manager taps the “AUTHORIZE” button  152  displayed in conjunction with the loan application displayed in  FIG. 13  and authenticates using the verification process to record approval.  FIG. 14  illustrates the process of entering the loan manager&#39;s session signature  154  on the manager access device  138 ; the manager access device  138  and the verification server  132  cooperate to compare the manager&#39;s session signature with the manager&#39;s reference signature and record authorization of the approval of the loan application if the two signatures are within predetermined parameters of each other. 
     After the loan manager approves the loan application, the customer receives on the applicant access device  134  an alert  160  that the loan documents are now ready for final approval.  FIG. 15  illustrates the process by which the user selects (e.g., taps on the applicant access device  134 ) the alert associated with the loan awaiting final approval. The loan document is displayed on the applicant access device  134  for final review and approval by the customer. 
     After reviewing the approved loan application, the customer taps the “AUTHORIZE” button  162  as shown in  FIG. 16  to indicate approval of the terms of the loan. As shown in  FIG. 17 , after the applicant taps the “AUTHORIZE” button, the applicant authenticates by entering their session signature  164  and pressing the authenticate button  166  on the applicant access device  134  to record the approval. In particular, the approval is recorded only if the session signature substantially matches the pre-approved reference signature previously entered by the user in the verification server  132 . 
     After the customer has recorded approval of the loan, the loan officer receives notification on the loan officer access device  136 ; the notification indicates that the loan application status has been changed to fully approved. 
     In the process described above, the manager first approved the loan application, and then the applicant approved the loan application in its final form. These two approvals need not be performed sequentially. The authentication systems and methods can instead be performed in parallel: the manager and the applicant are both simultaneously notified that the loan application is ready for approval, and the loan application status is changed to fully approved only after both the manager and the applicant have completed the approval process using the authentication systems and methods of the present invention. 
     III. Prescription Approval Example 
     Turning now to  FIG. 18  of the drawing, depicted therein is a prescription approval system  220  constructed in accordance with, and embodying, the principles of the present invention. The example prescription approval system  220  incorporates a communications system  222  such as the Internet and comprises a prescription server  230 , a verification server  232 , a requestor access device  234 , and a medical provider device  236 . 
     In the example prescription approval system  220 , the prescription server  230  is a combination of computer hardware and software forming an online service capable of storing and allowing access to the data required to process loan applications and generating reports based on such data. The example verification server  232  is a combination of hardware and software capable of storing data and performing a compare operation as will be described below. The example requestor access device  234  is a tablet such as an iPad, while the example medical provider device  236  is a smart phone such as an iPhone. However, a typical user may have multiple access devices, and different access devices may be used at different points in the process described herein. 
     As an alternative to using access devices  234  and  236  separate from the verification server  232 , the functions of the verification server  232  may be performed on one or both of the access devices  234  and  236 . As another alternative, more than one verification server  232  may be provided. 
     While verification server  232  and access devices  234  and  236  are depicted separately in  FIG. 18 , these verification services and access services may be performed on a single piece of hardware. For example, the medical provider access device  236  may contain software forming the verification server  232 . 
     After a medical appointment, the requestor (e.g., nurse) reviews the necessary prescriptions and issues a prescription request  237  as shown in  FIG. 19 . The requestor presses a save button  238  to save the prescription request  237  using the requestor access device  234 , and a notification is sent to the approving medical provider that approval of a prescription is requested. 
       FIG. 20  illustrates that the approving medical provider (e.g., doctor) receives an alert  240  on the medical provider access device  236  notifying the medical provider that a new prescription is awaiting approval. Alerts are viewed in this example by authenticating using a pre-approved signature as shown in  FIG. 21 . The approving medical provider taps the alert, authenticates with their pre-approved signature, and then reviews the prescription request. 
     In particular, after authenticating by entering a signature at  250  to view the details of the alert, a list  252  of prescriptions awaiting approval is displayed for viewing by the medical provider on the medical provider access device  236  as shown in  FIG. 22 . And as shown in  FIG. 23 , tapping on a displayed prescription request causes information associated with the selected prescription request  237  to be displayed on the medical provider access device  236  for review and approval by the medical provider. After the medical provider taps the alert, the example system  220  requests additional authentication to approve the prescription on the medical provider device as shown at  260  in  FIG. 24 . The medical provider may edit the selected prescription request if necessary. 
       FIG. 25  illustrates that the nurse/requestor receives notification in a list  270  on the requestor access device  234  that the medical provider has approved the prescription, and the requestor can take appropriate action. 
     IV. Authentication Systems and Methods 
     Turning now to  FIGS. 26-28 , an example authentication system  320  that may be used with any of the example systems  20 ,  120 , and  220  to authenticate whether an entered signature matches a reference signature associated with a particular user. Examples of the use of authentication systems similar to the example authentication system  320  described herein are described in the Applicant&#39;s Co-Pending U.S. patent application Ser. No. 14/501,554. The &#39;554 application is incorporated herein by reference to the extent that the teachings of the &#39;554 application illustrate examples of alternative authentication systems that may be used in place of the example authentication system  320  described herein. 
     The process of entering a signature for authentication purposes is shown, for example, in  FIG. 26 .  FIG. 26  illustrates that the example verification system  320  comprises a mobile device  322  comprising a display  324  that allows a user to enter a shape using a finger, stylus, or the like. In the example verification system  320 , the example mobile device  322  is used in conjunction with a verification server  326  as shown in  FIG. 27 . 
     Referring initially to  FIG. 26 , it can be seen that a handwritten entered signature depicted by solid lines  330  is entered on the mobile device  322 , and a pre-approved reference signature is indicated by broken lines at  332 . The reference signature  332  is depicted in  FIG. 26  for illustrative purposes only and would, in fact, not be displayed on the device  322 . 
     The handwritten signature  330 , which also may be referred to as a session signature, will be displayed as formed by the individual authorizing the transaction using the mobile device  322 . The handwritten signature  330  will be compared in software with the reference signature  332 , and the handwritten signature  330  will be verified only when it deviates no more than a predetermined amount from the reference signature  332 . As can be seen in  FIG. 26 , the handwritten signature  330  substantially matches the reference signature  332  and would likely be verified. It should be noted that the concept of “deviation” incorporates more than spatial or shape deviation. When the reference signature is generated, characteristics such as timing, speed, pressure, and the like may also be measured. Acceptable deviations in these additional characteristics may also be considered when determining whether the handwritten signature  330  substantially matches the reference signature  332  and is verified. 
       FIGS. 27 and 28A-28D  illustrate the process of preparing the mobile device  322  to authenticate the identity of the user by creating a reference signature such as the reference signature  332  described above. The process depicted in  FIG. 27  assumes that the mobile device  322  is loaded with an appropriate application and that the user has set up an appropriate profile. To create the reference signature  332 , the user first uses the mobile device  322  to identify the appropriate profile at a step  460 . The verification server  326  verifies the profile at step  462 . 
     At a step  470 , the user enters a first (calibration) signature using the mobile device  322  as generally described above.  FIG. 28A  shows both the first signature as represented by solid lines  480  and also represents the reference signature  332  using dotted lines. Again, the dotted lines are not actually displayed by the mobile device  322  but are depicted in  FIG. 28A  to provide a reference point to illustrate the ultimate creation of the reference signature  332 . The customer mobile device data associated with the first signature  480  is stored by the mobile device  322 . 
     At a step  472 , the user enters a second (calibration) signature using the mobile device  322 .  FIG. 28B  shows both the second signature as represented by solid lines  482  and also represents the reference signature  332  using dotted lines. Again, the dotted lines are not actually displayed by the mobile device  322  but are depicted in  FIG. 28B  to provide a reference point to illustrate the ultimate creation of the reference signature  332 . The customer mobile device data associated with the second signature  482  is stored by the mobile device  322 . Variations between the first and second signatures  480  and  482  are used to generate a first iteration of the reference signature  332  at a step  474 . 
     The process then returns to step  472 , at which point the user enters a third (calibration) signature using the mobile device  322 .  FIG. 28C  shows both the third signature as represented by solid lines  484  and also represents the reference signature  332  using dotted lines. Again, the dotted lines are not actually displayed by the mobile device  322  but are depicted in  FIG. 28C  to provide a reference point to illustrate the ultimate creation of the reference signature  332 . The customer mobile device data associated with the third signature  484  is stored by the mobile device  322 . Variations between the first, second, and third signatures  480 ,  482 , and  484  are used to generate a first iteration of the reference signature  332  at the step  474 . 
     After enough signature entries to create a reference signature representative of tolerances among all of the various signatures  480 ,  482 , and  484 , plus any additional signatures entered as may be necessary to reduce the likelihood of error during the validation process, the reference signature  332  may be represented by a reference signature as shown by  FIG. 28D , and  FIG. 27  shows that acceptable variances from the reference signature are stored as tolerances at step  476 . The reference signature  332  in conjunction with the variations as stored at step  476  thus incorporates variation data indicative of normal variations of actual signatures from the reference signature that are acceptable when determining whether a particular signature is valid. 
     V. Additional Considerations 
     The authentication systems and methods of the present invention may thus be used to log in to a device without a touch screen by entering a signature on a companion device having a touch screen. Authentication systems and methods of the present invention may also be used to approve of an electronic transaction such as a purchase, a loan application, or a prescription. And both of these uses may be combined: a user may perform most of the tasks of logging in and/or approving on a device without a touch screen, and then finalize or approve the transaction using a device with a touch screen.