Abstract:
Syncing two separate authentication channels to the same account or data using a token or the like is performed. Two authentication channels could be an online login and a mobile device login. Login for one channel creates a unique authentication code. When login from the second channel is desired, the login information is passed to the first channel device to obtain the appropriate authentication code. Then login at a service layer and data access are accomplished.

Description:
BACKGROUND 
       [0001]    Financial institutions (including banks, credit unions and other institutions that hold or process money for customers, clients, account holders or members, hereinafter “customers”) have recognized the desire of customers to access their accounts, view financial data, and perform transactions online from a remote location such as from a home or office rather than in-person in a physical bank, or credit union, stock brokerage, etc. Customers) often find online banking more convenient and efficient than having to visit a branch in person. Further, the number of customers that find online banking more convenient is increasing, and eventually online banking will handle the vast majority of customer transactions. 
         [0002]    To facilitate online banking, financial institutions (hereinafter “FIs”) establish their own online banking system or contract with an online banking provider (OLBP) which allows the FI&#39;s customers to access their accounts and perform transactions through a remote computer system rather than in-person at the FI&#39;s physical location. That remote location may be a desktop computer, or it may be a mobile electronic devices (“MED”) such as a smart phone, tablet computer, notebook computer, laptop computers, or other portable or mobile electronic device capable of accepting instructions from a customer. However due to size constraints, device limitations, the strong preference for native apps, etc., the standard OLBP experience does not normally work well on these MEDs. Consequently, each MED typically has its own application or app, potentially with a reduced set of features, different features, or otherwise differing from the OLBP experience. Consequently, the customers who use a MED may not have the same banking experience as customers who use a traditional personal computer to perform online banking functions. 
         [0003]    The OLBP will typically require a customer to log in before functionality is provided. Behind the OLBP login, optionally personal financial management (“PFM”) software provider can provide personal financial management functionality. This can include displaying account information for a user, and providing financial functionality such as, budgeting, account aggregation, reporting functions, and other money management functionality to the user. The PFM functionality may be accessed directly by the user logging in to the OLBP. Alternatively, the PFM functionality may be accessed by a user of an MED logging in to the PFM functionality via an app on the the MED. In the latter case, a problem of syncing account authentication from the OLBP log in (first channel) to the MED&#39;s app directly log in to the PFM functionality (second channel) presents a problem that must be solved. To explain it slightly differently, a customer can reach PFM functionality (the PFM service layer) through multiple paths, such as through OLBP directly or through an MED app. A technique must be used to reconcile those access paths so that a customer&#39;s identity is properly verified regardless of the access path or channel used. 
       SUMMARY 
       [0004]    Therefore, because customers can reach the PFM service layer and access PFM functionality through multiple paths in an online banking environment, such as through an OLBP or through a MED app, proper customer identity verification and account access must be provided regardless of the access path. If the user accesses the PFM service layer through an OLBP the user can be prompted with a user name and password. This is a traditional access method. Alternatively if the user accesses the PFM service layer through an MED app, the user can also be prompted for username and password. More information on this access technique is provided below. 
         [0005]    When the user logs in through the OLBP, widgets or some other software mechanism will lead the user to another window opening an application via a single sign-on from the OLBP to connect to the PFM functionality. The user uses the single sign on to sign into t PFM service layer and access PFM functionality. The OLBP announces the user&#39;s identity with a userkey, which may be a unique number or other unique key. The PFM functionality replies to the OLBP that it should populate certain data for that user. That information comes from a database accessible by the PFM functionality based on customer identity verification. The user or customer can then perform transactions supported by the PFM software utilizing that customer&#39;s account and historical data. 
         [0006]    When a customer is using an MED, there is a somewhat different experience. As previously mentioned, the MED will typically run a software application that differs in some ways from that available on the OLBP. This can be due to memory constraints, processor speed constraints, bandwidth constraints, screen size or other constraints on the MED. In time such constraints may be lessened, but are likely to exist for the foreseeable future. 
         [0007]    Through an MED login experience, the user will enter a username and password. But once the user has logged in in this fashion, there is a question as to how to determine that the mobile user is the same user who previously logged in through the OLBP. This is a problem because for the MED sign-in, the MED app does not pass the PFM service layer, as the app is already installed on the MED. Instead, the MED app just passes a userkey or other unique identifier to the PFM service layer. So when the user enters a user name and password into the mobile login, there is a problem determining which userkey or unique identifier to link it to. One possibility Is to create a whole new user account at the PFM service layer for the mobile user, but it is not desirable for a single customer to have two or more sets of data which must be reconciled at a sinfle FI. instead, it is preferable to simply point the mobile user to the same account and data accessible by the user from the OLBP so that the MED app can efficiently provide mobile customers with desired PFM functionality using their personal account and historical data stored on the FI&#39;s database. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0008]      FIG. 1  depicts an example architecture implementing the invention. 
       
    
    
     DETAILED DESCRIPTION  
       [0009]    The solution to the problem noted above is to create software functionality such that when a user enters his or her username and password into the MED, prior to accessing the PFM service layer, and attempts to access data, the software first will take the separate step of accessing the PFM service layer to login to that layer using the same username and password. The username and password have already been authenticated at the OLBP and a userkey or other unique identifier has already been created for it. Therefore when the MED passes a username and password to the PFM service layer, the service layer logs into the OLBP and enters the username and password. 
         [0010]    Using that mobile user name and password, the service layer logs into online banking and enters the username and password, and then looks for the userkey or other unique identifier that corresponds to that username and password. The OLBP provides that userkey to the PFM service layer, successfully identifying the user&#39;s account and permitting the PFM service layer to access its database and provide appropriate data and functionality to the MED user. 
         [0011]    What the system has done is take the userkey, which is known via the OLBP login, and paired it with the username &amp; password which is known from the mobile login. Because PFM service layer userkey is unique, that unique user&#39;s data may be accessed in the database connected to the PFM service layer, and the correct user&#39;s data is retrieved, including when login occurs through a MED. Therefore the user logging in through a MED will be paired correctly with that user&#39;s data, through username and password, and through the userkey or unique identifier verified through OLBP by the PFM service layer. This technique syncs the user&#39;s online banking experience with his/her mobile banking experience. These processes are transparent to the user and occur in milliseconds. 
         [0012]    Referring to  FIG. 1 , one implementation of the invented system, software and method is depicted. An OLBP  101  permits access or login via use of a username and password in order to provide online banking services. This is a single sign-on process (SSO) that is not repeated by the user or by software at the PFM service layer  102 . The login system creates a unique identifier such as a userkey which may be sent  103  to the service layer  102  for login. The unique userkey is used to create an account or match a user to an existing account. Only the unique userkey is sent to the back end. The userid and password are not sent to the back end. 
         [0013]    When the userkey is passed  103  to the service layer  102  a globally unique identifier (hereinafter “GUID”)  104  matches it to a user, such as “User A”  105  in the database  106  of user data (banking data, transactional data, etc.). This permits the user logging in through the OLBP to access his or her data and conduct online banking transactions. This allows the system to find the correct account and history data for a particular user, based on the GUID, which was based on a unique userkey, which was based on a username and password from the OLB login. 
         [0014]    Also referring to  FIG. 1 , when a customer uses an MED to employ PFM functionality, a different login procedure takes place. In this case, the user logs s in to a PFM app on his or her MED  107 , and there is standard a sign-in process  108  which uses username an password to let the user sign in to the app. But that alone does not establish login to the PFM service layer or access account data in the database  106 . The username and password that were used to log in to the MED cannot achieve login to the PFM service layer because from the OLB login, user name and password were not passed to the PFM. So after the user logs in to the MED app  108 , the MED app passes the username and password to the PFM service layer  102 , but not for direct login purposes. At the PFM service layer  102 , the username and password are then passed  113  back to the OLB in step  110  where login is performed to generate or obtain a unique userkey. That unique userkey from step  110  is then passed to the PFM layer  102  where it is matched  104  to the corresponding GUID. The GUID is matched via software process  111  to the user information  112 . Thus, the user is logged in at the PFM service layer and matched with that user&#39;s account data and history from the database  106 . 
         [0015]    It may be important to note that when a user logs in to the PFM layer from an MED, the MED does not simply log in through the OLB server. There is actually a separate software process in the PFM layer which sends the username and password from the MED login to the OLB in order to obtain the unique userkey associated with the user in question. That userkey is then sent to the PFM where it is matched with its corresponding GUID, allowing the userkey to be effectively matched to a user and his/her unique account and history information from the database. This allows the user to have the same account, data, transaction history, etc. regardless of when the user may switch from OLBP to MED and back again. At that point, the user should have essentially the same experience regardless of whether using OLBP or the PFM app on an MED. 
         [0016]    The invention has many uses across many industries, but is discussed herein with regard to a specific example of personal financial management software for the banking industry. Such specific discussion should not be considered to be limiting of the interpretation of the scope of the claims. Those skilled in the art will appreciate that variations and modifications may be made without departing from the principles of the invention as herein illustrated, described, and claimed. The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. All described embodiments are to be considered in all respects as only illustrative, and not restrictive. The scope of the invention is, therefore, indicated by the appended claims, rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.