Abstract:
A data gathering system is guided by an Internet-capable appliance associated with a user, which has a Pin Vault software instance executing from a digital memory media coupled to the appliance and a Pin Vault file stored in a data repository coupled to the appliance. The Pin Vault file comprises data for authenticating the user to one or more web sites storing information of interest to the user, and the Pin Vault software cooperates with an Internet service to provide, from the Pin Vault, data as needed by the Internet service to log onto and authenticate as the user at the one or more web sites storing information of interest to the user, to gather information on behalf of the user. The data for authentication is never kept at the Internet service.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    NA 
       BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention is in the field of Internet navigation including various communication means and connection technologies and pertains to systems and methods enabling Web authentication of users by proxy for gathering summary data and authorizing Web transactions. 
         [0004]    2. Discussion of the State of the Art 
         [0005]    In the field of Internet communications, particularly Web browsing activities, it is known that proxy servers exist and that a proxy service may perform tasks on behalf of a subscribing user, and may present the information to that user at some point in time that is convenient for the user. The inventor is aware of a service that aggregates data from one or more Web sites submitted by the user for the purpose, and can summarize the data for the user before presenting it or otherwise making the summary presentation available to the user. The service is accessible through a portal server functioning as a proxy or go-between. The server has software installed and configured to do summary searches based on Internet destinations and instructions provided by the subscribers. Information is retrieved from such destinations based on pre-programmed site information. The summary data can be accessed at the server or downloaded to the user&#39;s personal device for consumption. 
         [0006]    The software that enables the service includes a configuration and initiation interface for a subscriber to set up and start a summary search. In some cases retrieved information is immediately sent to the subscriber&#39;s personal device, and in other situations such information is saved at the portal server to be retrieved by a subscriber at a later time, or in some cases pushed to the subscriber at specified times. In preferred embodiments of the invention automatic logins are accomplished for a subscriber at Internet destinations by use of pre-stored configuration information and user authentication credentials. 
         [0007]    The subscribing user pre-provides the login data to the service in association with any site that requires the information. The service, using the appropriate site login data represents the user to the user&#39;s subscribed-to Web sites and services. Using this service saves the user from having to remember and repeatedly type in authentication data to get information from their Web locations. 
         [0008]    More recently, security regimens have been developed to elevate the level of security provided over the traditional username/personal identification number or password combination login credentials. One improvement is the advent of hardware or software Web token generators that are often used in conjunction with traditional authentication elements to authenticate a user. For example, a Web-based account or service may require the user to log in and provide, in addition to normal user credentials, a token that changes in value, say every 60 seconds. One popular method is to provide a hardware token generator that provides a unique token value at predictable intervals such as every 60 seconds. The hardware may be provided in the form of a universal serial bus (USB) device, for example. Soft token generators are also available for handheld devices like personal digital assistants and cell phones. The server accepting the token has prior information as to which token number value should be current for a particular user, based on the time intervals, and can perform a database lookup to compare a received token with the expected token and then determine whether to grant access based on the results of the lookup. 
         [0009]    Another relatively new development is CAPTCHA, which is an acronym for Completely Automated Public Turing Test to tell Computers and Humans Apart. CAPTCHA is a challenge/response test used in network computing to determine whether a requester of services is in fact human or a machine attempting to emulate a human. A server may be configured to initiate the CAPTCHA whenever a request for services is received. The test involves having the requestor look at a distorted character display and then type the correct sequence of characters into a provided input field associated with the display. The data received back at the server authenticates the requester as Human if the information is correct. Otherwise the requester is a machine that might be a malicious operator on the network. 
         [0010]    Both of the developments described above present a challenge for automated data aggregation and summary services. Because the Web-site access, authentication (if required) and data gathering is performed by software operating on a machine, it cannot complete automated proxy logins if CAPTCHA is required to gain access or to perform a transaction. In the case of time-sensitive tokens, the software described further above has no way of inputting or utilizing the unique user token data without the user&#39;s direct input. 
         [0011]    In examples and descriptions that follow, two-factor authentication generally comprises the following: There are typically three universally recognized factors for authenticating individuals: (1) Something a person knows, such as a password, a PIN or an out-of-wallet-response. (2) Something a person has, such as a mobile phone, a credit card or a hardware security token. (3) Something a person is, such as represented by a fingerprint, by a retinal scan, or by some other biometric. 
         [0012]    A system is said to leverage Two-factor authentication (T-FA, or dual factor authentication) when it requires at least two of the authentication form factors mentioned above. This contrasts with traditional password authentication, which requires only one authentication factor (such as knowledge of a password) in order to gain access to a system. 
       SUMMARY OF THE INVENTION 
       [0013]    The inventors in the present case recognized significant problems in requiring users to provide authentication information to on-line data-gathering services, which information would be stored at the data gathering service site, and therefore be vulnerable to misuse. As a result the inventors have provided, in one embodiment, a data gathering system having an Internet-capable appliance associated with a user, a Pin Vault software instance executing from a digital memory media coupled to the appliance, and a Pin Vault file stored in a data repository coupled to the appliance, the Pin Vault file comprising data for authenticating the user to one or more web sites storing information of interest to the user. The Pin Vault software cooperates with an Internet service to provide, from the Pin Vault, data as needed by the Internet service to log onto and authenticate as the user at the one or more web sites storing information of interest to the user, to gather information on behalf of the user. 
         [0014]    In another aspect the inventors have provided a data gathering system having an Internet site executing, from a digital memory media coupled to the site, data-gathering software browsing to Internet sites storing information of interest to the user, logging in and authenticating as the user, and gathering information from the sites for the user, and Pin Vault software executing on the site from the digital memory media, cooperating across the Internet network with an instance of Pin Vault software executing on an Internet-capable appliance associated with the user, accessing from a Pin Vault software instance executing from a digital memory media coupled to the appliance, authentication data from a Pin Vault file stored on the appliance. The Internet site follows configuration by the user to gather data on behalf of the user. 
         [0015]    In another aspect the inventors have provided a data gathering method of executing a Pin Vault software instance from a digital memory media coupled to an Internet-capable appliance, to cooperate with an Internet service to provide, from a Pin Vault stored in a data repository coupled to the appliance, data as needed by the Internet service to log onto and authenticate as the user at one or more web sites storing information of interest to the user, to gather information on behalf of the user. 
         [0016]    In yet another aspect the inventors have provided a data-gathering method of executing, from a digital memory media coupled to an Internet service site, data-gathering software browsing to other Internet sites storing information of interest to a particular user, logging in and authenticating as the user using authentication data retrieved from a Pin Vault file stored on an Internet-capable appliance associated with the user, and gathering information from the sites for the user. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING FIGURES 
         [0017]      FIG. 1  is an architectural overview of a system that can perform two-factor authentication on behalf of a user. 
           [0018]      FIG. 2  is a table representing client-side Web service and authentication credentials according to an embodiment of the present invention. 
           [0019]      FIG. 3  is an exemplary screen shot of a client side configuration interface according to an embodiment of the present invention. 
           [0020]      FIG. 4  is a process flow chart illustrating a two-factor authentication sequence by proxy leveraging a hardware or software token generator. 
           [0021]      FIG. 5  is a process flow chart illustrating a two-factor authentication sequence by proxy leveraging CAPTCHA input according to an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0022]    Referring now to  FIG. 1 , an overview of a communications network is illustrated and includes the Internet network  100  and a cellular wireless telephone network  101 . Internet network  100  is further defined by an Internet backbone  102  that represents, in this example, all of the lines, equipment, and connection points that make up the Internet as a whole. Therefore, there are no geographic limitations to the practice of the present invention. 
         [0023]    Internet  100  includes illustrated Web servers  104  and  109 , both coupled to backbone  102  for communication. Servers  104  and  109  serve electronic information pages (Web pages) ordered by users browsing the Internet by the user asserting a universal resource locator (URL). Servers  104  and  109  may be commercial Web sites through which online services are offered. 
         [0024]    A service provider  103  is illustrated in this example, and represents a service that provides Web information search and summary services for subscribers as well as providing certain transaction services for those subscribers as described in the background section. Service provider  103  maintains a portal server (PS)  105  that is adapted as a Web portal through which data aggregation, normalization and summary services are accessible to subscribing users. PS  105  is coupled to Internet backbone  102  for communication. 
         [0025]    A user domain  107  is illustrated in this example representing the domain of a user that subscribes to services offered by service provider  103  available through PS  105 . In this example, a personal device  108  is used by the subscriber/user to access PS  105  for services, in this case wirelessly through network  101  via a wireless link  111 . Network  101  includes a wireless Internet service provider (WISP)  106  that provides Internet connectivity to device  108 , which is a cellular telephone, in this example, capable of browsing the Internet. WISP has connection to Internet backbone  102  via an Internet access line  110 . 
         [0026]    In this embodiment device  108  is a personal handheld device that accesses PS  105  wirelessly. However, this should not be construed as a limitation to practice of the present invention. Device  108  may also be a PDA, a laptop computer, or a desktop computer adapted for wireless Internet access. Likewise, network  101  may be a public switched telephone network (PSTN) instead of a wireless network and device  108  may be an Internet Protocol (IP) telephone or a personal computer (PC) capable of accessing PS  105  using any available Internet access method like digital subscriber line (DSL), broadband, or modem dialup services. The inventor illustrates a cellular telephone and wireless connectivity as an example for discussion purposes only, and to demonstrate versatility of device type and access methods. 
         [0027]    As described above, a user operating device  108  may access PS  105  and access data aggregation and Web summary services to be performed on the user&#39;s behalf by proxy, and the user may not necessarily be connected during the time services are performed for the user. According to input from the user, PS  105  may navigate to various user-subscribed Web sites, such as those that may be maintained in servers  104  and/or  109 . PS  105  may log in representing the user and access specific data from those sites and even perform certain transactions at those sites, authorized by the user. 
         [0028]    The inventor provides an enhancement in this embodiment by providing a software application to run both client side and server side, the application termed a Pin Vault Application (PVA). An instance of server-side PVA  114  is provided to PS  105  and an instance of client-side PVA  112  is provided to personal device  108 . In one embodiment, the client-side PVA application  112  contains an encrypted user pin vault (UPV) file  113  that is adapted to store at minimum all of the user&#39;s subscribed-to Web site locations and appropriate authentication credentials for accessing those sites. UPV file  113  may be a small file downloadable to a cell phone, PDA, or other device that may be memory-challenged, but not necessarily so. Likewise, the UPV file may be stored locally on any PC or laptop computer. The authentication credentials and other data in the encrypted UPV file may also have two levels of encryption. Encrypted file  113  is made accessible to PVA  114  running on PS  105 . 
         [0029]    In this embodiment PS  105  does not retain any user authentication information locally. In this embodiment, when PS  105  is performing data aggregation and summary services for the user, it accesses UPV  113  from the user&#39;s device when needed to obtain the required data in order to access the appropriate Web sites and services. PVA  114  has the appropriate encryption/decryption software (SW) to decrypt and use the user authentication credentials from UPV  113 . The entire process is automated at server side and no human operator has access to the decrypted data of the user. 
         [0030]    PS  105 , in addition to PVA  114 , has a gatherer software (GSW) agent application  115  installed and executable thereon that may spawn multiple individual instances for performing the offered services including performing site login authentication and data aggregation. In one embodiment, a single gatherer instance is responsible for gathering information from one site. Therefore, a user that has several sites may have several gatherer instances working to perform server side data aggregation and summary services simultaneously. 
         [0031]    GSW  115  also includes a configuration and initiation software (CISW) interface that is accessible to device  108  and may be used to configure and to initiate or activate services. In applications known to the inventor without PVA  114  or  112 , the user submits the required Web site access and authentication data to PS  105  for storage. In this case, PS  105  can only log into sites that do not require a two-factor authentication using time sensitive tokens or CAPTCHA displays. Provision of PVA  112  on device  108  enables the user to keep the sensitive information stored locally in encrypted format. In this embodiment, the user participates passively in the process of server-side data aggregation and summary by making the device accessible to PS  105  during the course of service performance. 
         [0032]    In this embodiment PS  105  aided by PVA  114  may access device  108  as needed and interrogate UPV  113  to obtain required site location information and authentication data needed to access the sites. In an embodiment where one or more sites use time sensitive tokens as part of the two-factor authentication, PS  105  may obtain the correct token file from device  108  at the same time the standard authentication credentials are obtained at the time of login to the site. In this embodiment, the user need not provide any direct input so long as the correct token file is automatically generated and made available, in this case, within UPV  113 . 
         [0033]    In the case that any of the user&#39;s sites require submission of CAPTCHA data, those CAPTCHA displays, including the appropriate data entry boxes, may be captured from those sites and then submitted to device  108  at which time the user operating the device may type in the appropriate characters required by the site as part of the two-factor authentication. The CAPTCHA data is submitted at the time of login attempt after the user has received the CAPTCHA display from PS  105 . PS  105  may retrieve the user login credentials and accept the user-submitted CAPTCHA data in the same transaction. 
         [0034]    The first embodiment described above, using tokens only, requires that the device containing UVP  113  be powered on and connected to PS server  105 . No direct participation is required of the user. In the case of a device using a USB token generator or some other hardware generator, the hardware should be connected to the device with the device connected online to PS  105 . The hardware device should be one that automatically generates tokens without direct human input activity. If required, a human may be present to provide the token input for hardware that requires a user to depress a button or perform some other action to render the token at the time of login. 
         [0035]    In both of the embodiments described above, the PVA software ( 114 ,  112 ) enables the user to store their own credentials locally and still benefit from server side performance power. In one embodiment, a user may also elect to transmit some or all of their UPV data to PS  105  for permanent or temporary storage. 
         [0036]    A client may elect to schedule automatic refreshes of their summary data using PVA  112  and the client may also elect to manually refresh their summary data using PVA  112 . A user interface (not illustrated) provides this functionality. Likewise, PS  105  aided by PVA instance  114  may detect when the user of device  108  is online and may initiate a connection to device  108  to request that it refresh the client&#39;s summary data. More detail about a PVA user interface is provided below. 
         [0037]    In this embodiment, PVA software also enables the client to move credentials from a device such as device  108  to the portal server (PS  105 ) or from the server to the device. Moreover, the client may destroy the credential on the device or at the server remotely. The service provider may also destroy the credentials locally at the server or remotely at the client device depending on circumstances. 
         [0038]    Referring now to  FIG. 2 , UPV  113  is logically illustrated in table form. In this example, UVP  113  bears a title “My Pin Vault” however other titles, logos, trademarks, and other information may also appear in a title bar or block. Table  113  may or may not be displayable and may vary widely in displayed format if it is displayable. 
         [0039]    In this example, the table is divided into several columns and rows adapted to organize the client information and credentials. A column  201  headed URL lists the Web site navigation addresses to client sites. In this case, even the site URLs are encrypted and listed in no particular order in the adjoining rows of the table in column  201 . A column  202  headed User Name lists the appropriate user names that the client has set up for the appropriate Web site addresses listed in column  201 . All of the client&#39;s user names are encrypted in this example. A column  203  titled PIN/Password lists the appropriate PIN numbers and/or passwords that the client has associated with the appropriate usernames in column  202  for the appropriate addresses listed in column  201 . The PIN and/or passwords are also encrypted. 
         [0040]    It is important to note herein that the credentials may only be decrypted when being used by automated software to authenticate access or to authorize a transaction on behalf of a user preventing any human other than the client from accessing the information. 
         [0041]    In this embodiment, table  113  has an additional column  204  titled Token File. Column  204  lists the current generated token files required in a two-factor authentication embodiment that correspond to the appropriate credentials in columns  203  and  202  for the appropriate site addresses listed in column  201 . In column  204 , there may or may not be any tokens listed as some site addresses may require token authentication as part of a two-factor authentication and some may not. In this example, there is a token for each listed site assuming that all of the sites listed in this embodiment require a token as part of a two-factor authentication. 
         [0042]    Each token file is different from any other token file listed and the revolving placement of token files into each cell under column  204  depends on the specified time to live for each token instance. For example, in the first row under token file, a next token would be accessible after the current token expires, perhaps every 60 seconds or some other arbitrary period. In this example, PS  105  of  FIG. 1  aided by SW PVA  114  may access UPV  113  at the client&#39;s device and may obtain any row of credentials, including the current token, when PVA  114  is performing a login to authenticate access to a site or to authenticate a transaction at a site. It is important to note herein that if a token expires just before a login attempt, the software may automatically retry the authentication using the next token generated. 
         [0043]    Referring now to  FIG. 3 , a pin vault user interface (UI)  300  is illustrated. UI  300  resides either on PS  105  of  FIG. 1  or on the client device such as device  108 , and may be an integrated part of PVA. UI  300  may include a title bar  301  identifying the interface. The title bar may include any pertinent information identifying the interface and version, trademark information, logo, personal client name, etc. 
         [0044]    UI  300  includes an online status window  302  that shows the user if there is any current proxy activity taking place at the time. In this instance, the service is logged into a URL on behalf of the client. A client may activate interface  302  and watch the activity performed by the service at any time. Other status indicators might be present without departing from the spirit and scope of the present invention like a time window indication the time the service took to perform certain processes for the user at specific sites and for an overall aggregation and summarization sequence involving more than one site. In some cases the status window may show more than one URL at a time indicating that more than one instance of gatherer is working simultaneously for the user. 
         [0045]    Status window  302  has an option initiated by button  303  for performing manual refresh of data. A user may select this option to initiate another round of refresh at any time. Status window  302  also includes a remote refresh interface that can be initiated remotely by the service from PS  105  of  FIG. 1 . The user may retain the right not to allow remote refresh capability if so desired. If allowed, the service may set a refresh schedule for the user. The user also has an option for scheduling refreshes of data for each individual site or for all of the sites submitted for server-side summarization services. This option is provided in window  305  adapted for configuration, and described below. 
         [0046]    UI  300  includes a configuration window  305  adapted to enable a user to set and initiate preferences including scheduled refreshes. Configuration window  305  includes an interactive status indicator button  306  that when activated shows at least some portion of recent activity history. Another status indicator button  307  is provided that when activated shows some statistics such as error rates, percentages of successful login and aggregation sequences, and other like data. An interactive button  308  labeled Web sites enables a user to see the registered sites and to add new sites or delete existing sites from the service. 
         [0047]    UI  300  includes an interactive button  309  adapted to enable the user to configure an automatic refresh interval for one or more sites registered to the service. Activation of option  309  may bring up a new window  310  listing site URLs and providing a column for entering a refresh rate for each listed site. In this example, a URL www.mybank.com is listed where the user has indicated a refresh rate of each day. A next URL, www.mystock.com has a refresh rate ordered for every hour. There are many different possibilities. 
         [0048]    Referring now to  FIG. 4 , a process is illustrated for practicing the invention using a two-factor authentication sequence that requires use of a token as part of the authentication sequence. 
         [0049]    In step  401 , the user makes a determination if a manual refresh is appropriate. If in step  401  the user determines to manually refresh data for a site, for example, then in step  402 , the system makes a determination if the login is a two-factor login that requires a token. If in act  402 , the system determines that no token is required, then the authentication may not be a two-Factor authentication, in which case the process moves directly to step  404  where the system obtains the UVP credentials for login to perform data gathering. Alternatively, if there is no token required in step  402  and the nature of the activity for the site is to perform a transaction instead of gathering and summarizing data, then the process moves to step  408  from step  402  where the system receives the credentials for authenticating one or more ordered transactions. The sequence described above can be one that begins at step  407  if the user decides to request a transaction instead of step  401 . 
         [0050]    If in act  402 , the system determines that a token is required as part of a two-factor authentication then at step  403 , the system determines the time to live for the current token. If an order is login in to the site to perform data gathering, as ordered in step  401 , then in step  404  the system obtains the credentials including the current token to use in the two-factor authentication for login. In any case scenario, in step  405  the system passes the required credentials in encrypted form to the gatherer software agent and in step  406  the gatherer agent uses the credentials and the token to perform authentication and login on behalf of the user. 
         [0051]    If the user determines not to refresh in step  401 , then in step  407 , the user determines whether to request a transaction. If in step  407  the user decides to request a transaction, and in step  402  the system has verified a token is required and has determined the token life in step  403 , then at step  408  the system obtains the required credentials and the token from the UPV client and in step  409  the data is passed in encrypted form to a transaction agent. In step  410 , the transaction agent uses the credentials including the token to perform a transaction on behalf of the user. In this case, more than one transaction may be performed if allowed by the site using the same credentials and token. If the token expires during the course of transacting, the system may obtain the next token from the client UVP. 
         [0052]    In either of the above sequences whether logging in to a site or authenticating a pending transaction, if the token part of the credentials fails then the system may automatically reattempt the sequence after obtaining a current token from the user. Also, either sequence may be initiated from steps  401  or  407  independently without departing from the spirit and scope of the present invention. If in step  401  there is no refresh request and in step  407  there is no transaction request then the process may terminate in step  411  or cycle without doing anything. 
         [0053]    The only difference in the process sequences for a two-factor authentication whether for initial login or for performing a transaction is that the system obtains the token along with the standard username and password and/or PIN credentials to use to authenticate as the user. Also in this case whether a token is required or not, it is assumed that the user has the required credentials stored locally on his or her device and that the system must obtain them from the user. In cases of single factor authentication there is no token and the user may not be required to participate at all if the credentials are stored locally to the system by way of user permission and previous submission of the data. However, the user device must participate in authentication if two-factor authentication is required in order that the system has the correct and current token for successfully completing a login or transaction authentication procedure. 
         [0054]    Referring now to  FIG. 5 , a process is illustrated for two-factor authentication wherein a CAPTCHA display interaction is a second part of authentication. The process may begin with a refresh request in step  501  or with a transaction request in step  508 . If in step  501 , the user requests a refresh then in step  502 , the system determines if there is a CAPTCHA requirement as a part of a two-factor authentication. If the system determines that there is no CAPTCHA requirement in step  502 , then the process may terminate in step  511  or cycle back to step  508 . 
         [0055]    If in step  502 , the system determines that a CAPTCHA requirement exists to login, then at step  503 , the system notifies a configuration and initiation interface that a CAPTCHA interaction is required, and in step  504  provides the interface with the address location for receiving the display. In the meantime, the gathering SW remains in a hold state waiting for information. In step  505 , the configuration and initiation interface retrieves the CAPTCHA display required by the site and presents the display to the device of the user along with the appropriate data entry box or field for the user to type in the required characters. 
         [0056]    Assuming the process began with a refresh request in step  501 , in step  506  the configuration and initiation interface passes the user-submitted CAPTCHA data to the gatherer agent. The system may have already obtained the user&#39;s credentials from the client UVP and passed that information to the gatherer. In one embodiment, the system may interrogate the user UVP via the server-side PVA instance and the user credentials are passed to the gatherer from the PVA application while the CAPTCHA data arrives at the gatherer via the configuration and initiation interface. In another embodiment, one SW transaction is used to submit the CAPTCHA data and the username password/PIN credentials to the gatherer. In any case, the gatherer agent uses the credentials and the CAPTCHA data to authenticate the user in step  507 . 
         [0057]    If the process starts with step  508  where a transaction is requested, then in step  502  the system determines if CAPTCHA is required as part of a two-factor authentication required by the site to allow the transaction. If in step  505  the system determines that CAPTCHA interaction is required then steps  503 ,  504 , and  505  are undertaken as with the request refresh sequence. However, after the user has submitted the CAPTCHA data, the configuration and initiation interface passes at least the CAPTCHA data to the transaction agent in step  509 . Since a gatherer agent is not performing a site login in this example, the configuration and initiation interface may be charged also with obtaining the user credentials from the client UVP and passing the data along with the CAPTCHA data to the transaction agent in step  509 . In step  510 , the transaction agent uses the credentials and CAPTCHA data to authenticate the user for the transaction. 
         [0058]    If in step  501  no refresh is ordered and in step  508  no request for transaction is ordered, then the process may terminate at step  511  without doing anything. Where CAPTCHA is required, it may be that the system already has the standard user credentials stored locally at the server and therefore only the CAPTCHA input has to be obtained from the user. The process described in this embodiment may be combined with the process described further above concerning token requirements to produce a process that accurately determines the specific requirements of both login and transaction authentication procedures site by site and depending on the results proceeds accordingly down the tree incorporating only the required steps. 
         [0059]    A user may initiate a refresh for all of the registered sites at one time, some of which may be two-factor authentication sites requiring CAPTCHA and some requiring token authentication. Some of the sites subject to processing may not require two-factor authentications. Sites in the latter category can also be processed using PVA assistance without departing from the spirit and scope of the present invention. The only difference being that the steps for obtaining tokens or retrieving CAPTCHA displays and presenting them to a user would not be required. Still relevant to the invention is the accessible UPV file containing all of the user&#39;s credentials stored locally in an encrypted format. 
         [0060]    It will be apparent to one with skill in the art that the PVA service and system of the invention may be provided using some or all of the mentioned features and components without departing from the spirit and scope of the present invention. It will also be apparent to the skilled artisan that the embodiments described above are exemplary of inventions that may have far greater scope than any of the singular descriptions. There may be many alterations made in the descriptions without departing from the spirit and scope of the present invention.