JP2010506312A - Reliable multi-channel authentication - Google Patents

Abstract

  The present technology describes a method and apparatus, and includes a computer program product for allowing a user to access resources using multi-channel. The first authentication parameter from the first device is received via the first channel, and the token value and the second authentication parameter are received via the second channel. The token value is used to associate the first authentication parameter and the second authentication parameter. Enabling or disabling user access is based on the association of the first authentication parameter and the second authentication parameter.

Description

  The present invention relates generally to using multi-channel to allow users access to resources and to using multi-channel when authenticating a single user or many users.

  Electronic mail order relies on reliable and accurate authentication of end users. The emergence of a wide range of successful attacks on simple user credentials (user ID and password) jeopardizes the user's ability to conduct electronic commerce. Due to attacks, users are exposed to a significant risk of financial loss, identity theft and / or other nuisance. Attacks such as desktop viruses, key loggers, man-in-the-middle environments, phishing and farming all overlap to compromise the user's personal information, but users are often unaware of this problem.

  The fear of attacks increases the cost of doing service provider business. Service providers must spend money to defend against attacks, compensate the attacked user, and reassure the user that electronic sales are secure. Eventually, when a user fails to provide a mechanism for successful and reliable authentication, it compromises the user's trust in electronic commerce and threatens the electronic channel as a viable means of doing business.

  Electronic channel authentication often requires the presentation of both personal information data and shared sensitive data. Shared confidential data is known only to users and service providers and establishes personal user information with a certain degree of reliability. This form of authentication is vulnerable to eavesdropping attacks. If an attacker gains both personal information data and shared secrets, the attacker becomes indistinguishable from a legitimate party as seen by the service provider. The attacker intercepts the exchanged data by processing the terminals of the electronic channel.

  Many service providers improve this basic data exchange by incorporating mechanisms that change sensitive data over time in an unpredictable way. Even if only confidentiality is captured in this way, the user is compromised until the next change. Unfortunately, the mechanism for changing the secret may increase the cost of the service provider and make it inconvenient for the user. For example, the user may forget any device that provides changed secrets. In this case, the service provider must provide not only authentication augmented by periodic exchanges, but also an alternative authentication process that allows the user to bypass periodic exchange authentication if the user forgets the device. This may require an additional authentication step by the user or limit the user's access.

  In one approach, multi-channel may be used to authenticate the user. In one aspect, this is a method in which the user is not authenticated, including receiving a first authentication parameter from a first device connected to the user via a first channel. The method also transmits a token value and receives the token value and the second authentication parameter from the second device via the second channel, and the second device is connected to the user; using the token value Associating the first authentication parameter with the second authentication parameter.

  In another approach, the method accesses a resource via a first channel, and the resource requires a second authentication parameter via a second channel. In one aspect of this approach, the method receives a request for a resource that requires a second authentication parameter via a first channel; transmits a token value via the first channel; and the token value via a second channel. And receiving the second authentication parameter; associating the request received via the first channel with the second authentication parameter received via the second channel using the token value.

  In another approach, multi-channel is used to provide resources to the first party, where access to the resources requires an indication of approval from the second user. In one aspect, a method receives a first authentication parameter from a first device, the first device connects to a first user, and a request for a resource that requires an indication of approval of a second user from the first user. And transmitting a token value to the first device. The method also receives a second authentication parameter and the token value from a second device, wherein the second device is connected to the second user and uses the token value to set the second authentication parameter. Associating the first authentication parameter, receiving an approval indication from the second user and authorizing the request from the first user.

  In another aspect, the method authenticates a first user on a first channel, receives a request for a resource from a first device via the first channel, and the request requires an indication of approval from the second user; Here, the first device is connected to the first user, and includes transmitting a token value to the first device. The method also authenticates a second user on a second channel and receives the token value from the second device via the second channel, wherein the second device is connected to the second user, and Receiving an indication of the approval from a second device. The method also includes associating the request from the first device with the approval indication from the second device using the token value and providing the resource to the first device.

  In another aspect, the method authenticates a second user and receives a token value, wherein the token value is associated with a user session, wherein the first user displays an approval from the second user. Based on accessing a resource, transmitting information about the user to the device, and receiving instructions from the device regarding the first user's access to the resource.

  Embodiments described above can include one or more of the following features. The user can be authenticated based on the first authentication parameter and the second authentication parameter. The first authentication parameter may be a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof. The second authentication parameter can be a user ID, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof. The first authentication parameter and the second authentication parameter may be channel specific. The user can be notified via the second channel that the authentication is complete, and the user can continue a user session on the first channel. The first channel can be a telephone line, wireless connection or online connection, and the second channel can be a telephone line, wireless connection or online connection.

  Also, the above-described aspects can include receiving the token value and at least one additional authentication parameter via at least one additional channel. The additional authentication parameters include a user ID, a password, a partial password, a part of the first authentication parameter, a part of the second authentication parameter, a combination of the first and second authentication parameters, a hard token, a soft token, and a wireless applet. , A voiceprint or any combination thereof. The additional channel may not be the first or second channel, and the token value may be used to associate the first authentication parameter, the second authentication parameter and at least one of the additional authentication parameters. The first authentication parameter, the second authentication parameter, and at least one additional authentication parameter may be used to authenticate the user.

  Any aspect of the aspects described above can include one or more of the following features. The resource may require a second authentication parameter and at least one additional authentication parameter. In addition, the method receives the token value and the additional authentication parameter via an additional channel, and receives the additional authentication parameter received via the additional channel using the token value via the first channel. It may include associating the request.

  Any aspect of the aspects described above can include one or more of the following features. The resource is supplied via the first channel. The method also receives a request for a resource that requires an additional authentication parameter via the first channel, receives the token value and the additional authentication parameter via an additional channel, and uses the token value to add the additional value. Associating the request received via the first channel with the additional authentication parameter received via the channel. The additional authentication parameter may not be the first authentication parameter or the second authentication parameter in some aspects. The additional authentication parameter may require more than either the first authentication parameter or the second authentication parameter in an additional or alternative manner. And the additional authentication parameter can be a user ID, password, partial password, hard token, soft token, wireless applet, voiceprint, or any combination thereof in some other aspects.

  In addition, any of the above-described aspects may include one or more of the following features. At least one additional user supplies the token value via at least one additional channel. The additional user may be authenticated using single channel or multi-channel authentication before supplying the token value. At least one of the additional users provides an indication of approval for the first user and receives the requested resource, authentication parameter, token value or any combination via the first channel via at least one of the additional channels. May be.

  In addition, any of the above-described aspects may include one or more of the following features. The resource can be supplied via the first channel and the second channel at the same time. The first channel can be a telephone line, wireless connection or online connection, and the second channel is a telephone line, wireless connection or online connection.

  In addition, any of the above-described aspects may include one or more of the following features. The user may be authenticated using a multi-channel authentication process or a single channel authentication process. The method can also include authenticating the user by receiving a first authentication parameter from the first device over the first channel. The first device can be connected to the user. Further, the aspect may include one or more of the following features. The first authentication parameter may be a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof. The second authentication parameter can be a user ID, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof. The second authentication parameter may not be the first authentication parameter. The second authentication parameter may require more than the first authentication parameter. The first authentication parameter and the second authentication parameter may be channel specific.

  Also, any aspect of the aspects may include one or more of the following features. A credential is generated, wherein information related to the credential may be supplied to the first device without the second authentication parameter being supplied via the second channel. Can be shown. The credential may be a permanent credential, a time sensitive credential, a credential that expires after a predetermined number of user sessions, or any combination thereof. Other features in some aspects may include a case where the user attempts to start a new session that leaves the initial session and authenticates the user. The method may also include receiving a request for the resource from the first device via a first channel. The resource may require the second authentication parameter supplied via the second channel. The method also processes information associated with the credential; the information associated with the credential does not provide the second authentication parameter via the second channel, and the resource is associated with the first Providing to a device can include providing the resource.

  Any of the above aspects can include one or more of the following features. The first authentication parameter can be received from the first device. The method also receives a first authentication parameter from the first device via the first channel, receives a second authentication parameter and the token value from the second device, and receives the first authentication parameter from the first device via the first channel. Receiving an authentication parameter and associating the request received from the first device with an indication of the approval from the second user received from the second channel using the token value; Providing the resources can be included.

  Any of the above aspects can include one or more of the following features. The first authentication parameter may be a user ID, a descriptive title, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof. The first authentication parameter may be associated with the second user. The second authentication parameter may be a user ID, a descriptive title, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof.

  Any of the above aspects can include one or more of the following features. The user can be authenticated using a single channel process or a multi-channel process. The method receives a user ID and a first password associated with the first user via the first channel, authenticates the first user based on the user ID and the first password, and sets the second channel. And receiving a user ID and a second password associated with the second user, and authenticating the second user based on the user ID and the second password.

  Any of the above aspects can include one or more of the following features. A credential may be generated with information, which indicates whether resources are provided to the first device without an indication of approval from the second user. The credential may be a cookie, a permanent credential, a time sensitive credential, a credential that expires after a predetermined number of user sessions, or any combination thereof. Other features may be included in one or more of the above aspects, but include the case where the first user attempts to leave a first session and start a new session. The method can also include authenticating the first user. The method can also include receiving the first authentication parameter from the first device. The first device may be connected to the first user. The method also receives a request for the resource from the first device, wherein access to the resource requires an indication of approval from the second user and processes information associated with the credential. Can include. Additional features may be included in one or more of the above aspects, but information related to the credential should be provided to the first device without the second user's approval. Indicates that the resource is provided.

  Any of the above aspects can include one or more of the following features. Authentication parameters can be received from the device. The authentication parameter may be associated with the second user. The method also receives an instruction from the second user to terminate the access of the first user to the resource, receives an instruction from the second user, and the first user to the resource Restricting access can be included. The second user can then limit the access of the first user according to a deadline or a predetermined number of user sessions.

  Any of the above aspects can include one or more of the following features. The first authentication parameter can be a user ID, a descriptive title, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof. The first authentication parameter may be associated with a second user or a first user. The second authentication parameter can be a user ID, a descriptive title, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof. The second authentication parameter may be associated with the first user or the second user. The second authentication parameter may not be the first authentication parameter. The second authentication parameter may require more than the first authentication parameter. The first authentication parameter, the second authentication parameter, and the additional authentication parameter can be channel specific. The additional authentication parameter may not be the first authentication parameter or the second authentication parameter. The additional authentication parameter may require more than either the first authentication parameter or the second authentication parameter. The additional authentication parameters include a user ID, a password, a partial password, a part of the first authentication parameter, a part of the second authentication parameter, a combination of the first and second authentication parameters, a hard token, a soft token, a wireless It can be an applet, a voiceprint, or any combination thereof.

  In another aspect, there is a computer program product for generating code over a network. The computer program product is clearly embodied in an information carrier. The computer program product includes instructions that can be executed to cause the data processing apparatus to perform any of the above methods.

  In another aspect, there is a system for generating code over a network. The system includes a computing device. The arithmetic unit is configured to perform any method among the above methods.

  Any of the methods and / or apparatus described above can include one or more of the following advantages. The advantage of the disclosed technique is that the user does not supply all of these authentication parameters via a single channel. If an outsider intercepts a user's session, the outsider cannot later access the session, for example, because the outsider does not have access to the user's user ID and password, for example. Furthermore, if the third party has access to the user ID and password, the third party will not be able to complete the transaction or access resources that require additional authentication parameters. Another advantage of the disclosed technique is that, for example, the second user's user ID or other first authentication parameters in alternative embodiments may be exposed, but the second user's password or second authentication parameters are not exposed. . The first user can then access the account information of the second user or registered user with limited exposure of the second user's authentication parameters. Another advantage is that the technique can be modified to authenticate or authorize a single user or a group of “N” users. Furthermore, the authenticated or authorized user does not need to have a previous relationship with the resource provider or the back end system provider.

  Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

  The above and other objects, features and advantages of the present invention, together with the present invention itself, will be more fully understood when the following description of various embodiments is read with reference to the accompanying drawings.

Figure 2 illustrates elements of a multi-channel authentication process. 2A-2C illustrate a single, participant, multi-channel authentication process. 3A-3C illustrate a higher level authentication process that accesses limited resources for a single participant over multiple channels. 4A-4C illustrate a more advanced authentication process that accesses limited resources for a single participant over multiple channels, where the device is also registered as secure for future sessions. 5A-5C illustrate an authentication process used by multiple parties via multi-channel. Indicating a process, a user registered by this process terminates the first user's access to the requested resource. FIGS. 8A-8C illustrate an embodiment in which a parent or second joint account owner must authorize a minor or first joint account owner session. 8A-8C illustrate a multi-channel authentication process for credit card transactions.

  Variations, modifications and other implementations of what is described herein will now be apparent to those skilled in the art without departing from the spirit and scope of the invention. Accordingly, the present invention should not be limited by the following illustrative description.

  The techniques described herein allow a single user to authenticate to a single session using at least two different channels sequentially. By using multi-channel, the user is prevented from supplying all of the user's authentication or personal identification information via a single data stream channel that may be intercepted. In addition, if one data stream is intercepted by a third party who attempts to improperly access the user's personal information, the third party may use any intercepted information and then use the user's account or The personal information is not accessible because the third party does not have access to all of the user's authentication information, but only to the authentication information passed through the intercepted channel or data stream. Thus, access to the user's account or personal information is protected.

  One embodiment of these techniques involves a single user authenticating its use using multi-channel. Also, many users can use multi-channel authentication / authorization techniques.

  FIG. 1 shows a system that can be used in some embodiments. The system includes, for example, a user agent 1101, a first channel 5, a user agent 2102, a second channel 6, at least one additional user agent 103, at least one additional channel 7, and a back end system 100. be able to. The back end system 100 communicates with different channels 5, 6, 7 and uses interfaces and / or networks connected to each channel (not shown). The user can supply the first authentication parameter via the first channel 5. The back end system 100 includes a token generation module 100a that generates a token value and sends the token value to the user via the first channel 5. The user takes the token value and uses the second channel, where the user enters the token value and the second authentication parameter. This process of entering the token value and additional authentication parameters can be repeated on an unlimited number of different channels. The back-end system 100 includes an authentication module 100b, which uses the token value to provide authentication parameters or authorizations supplied via the second channel 6 and / or additional channel 7 to resources on the first channel 5 or Associate a request for authentication. In some embodiments, the back end system 100 can be a single device, and in other embodiments, the back end system 100 can include multiple devices. Modules 100a and 100b may be part of the same device or distributed on different devices as well. In some embodiments, the user may select a different second or additional channel each time they complete the second part of the authentication process. In some embodiments, the user must select the first and second channels to ensure that not all of the data being transmitted passes through the same data stream. This ensures that if a channel is intercepted by an unauthorized third party, not all of the user's personal or authentication parameters are in danger.

  User agents 101, 102, 103 are computers, telephones, IP phones, mobile devices (eg, mobile phones, personal digital assistant (PDA) devices, laptop computers and / or others) and / or other communication devices. Can be.

User agent 1101 can be connected to a first user or a first device. In some embodiments, user agent 1101 can include a first device, and in some other embodiments, user agent 1101 can be both the first channel 5 and the first device. Similarly, user agent 2102 can be connected to a second user or a second device. In some embodiments, the user agent 2102 can be a second device, and in some other embodiments, the user agent 2102 can include both the second channel 6 and the second device.
The information entered by the user on the first channel 5 and the information entered on the second channel 6 or the additional channel 7 are related by tokens. The advantage of the token value is that it allows easy association of user authentication parameters entered via multiple channels.

  In some embodiments, user agent 1101, user agent 2102 and any additional user agent 103 are connected to a single user. In some embodiments, each user agent is connected to a different user.

  In some embodiments, the token value is used when authenticating a user or multiple users over multiple channels. In the first embodiment, the token value may ensure that only the device and user are authenticated and that other unauthorized users connected to other equipment do not have access to the user's information or trading authority. . Also, token values can be mapped and returned to database records and one or more users in some embodiments. The token value can associate a first authentication parameter connected to the first channel and a second authentication parameter connected to the second channel. The token value can be used to associate the Nth parameter with an arbitrary parameter among the N-1 parameters previously input. In some embodiments, the token value may associate a request received via the first channel with an indication of authorization from an authenticated user received via the second or Nth (additional) channel. And in some embodiments, the token is entered with authentication data or parameters, not alone or simply with an indication of approval.

  In some embodiments, the user may determine the relative security strength of the token, and in some embodiments the resource provider may determine the token strength. In some embodiments, the token value can be, for example, a randomly generated alphanumeric string that is encrypted and known in advance by the account owner or registered user, and the requested resource or It is specific to the authentication level and can be further assured by the requested resource or authentication level or any combination thereof. In some embodiments, the token value may be limited by the number of transactions, time restrictions, or specified by session. And in some embodiments, the token may be unique to the event or scenario.

  The transfer of information via the first channel 5, the second channel 6 and / or at least one additional channel 7 can be based on one or more communication protocols and / or communication modes. Communication protocols include, for example, Internet Protocol (IP), Voice over IP (VOIP), Peer to Peer (P2P), Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), Really Simple Syndication (RSS) ), Podcasting, Signaling System # 7 (SS7), Global System for Mobile Communications (GSM), Push to Talk (PTT), Mobile Phone PTT (POC) and / or other communication protocols it can. Communication modes range from textual aspects (eg, email and / or instant message) to graphical aspects (eg, still and / or video) or audio aspects (eg, voice call) or any combination thereof Can range.

  The first channel 5, the second channel 6 and / or the at least one additional channel 7 can include one or more packet-based networks and / or one or more circuit-based networks in any configuration. Packet-based networks include, for example, the Internet, Carrier Internet Protocol (IP) networks (LAN, WAN, etc.), private IP networks, IP private branch exchanges (IPBX), wireless networks (eg, Radio Access Network (RAN)) and / Or other packet-based networks may be included. Circuit-based networks can include, for example, a public switched telephone network (PSTN), a legacy private branch exchange (PBX), a wireless network (eg, RAN), and / or other circuit-based networks.

  The first channel 5, the second channel 6 and the additional channel 7 can be connected directly or indirectly to the back end system 100. The back-end system 100 includes, for example, an authentication server, an authentication verifier, an ID system, a session database, a wireless gateway server, a low value resource verifier, a high value resource verifier, a resource verifier, a thermy application, and a voice authentication verifier. And a VRU gateway.

  FIG. 2A shows a first embodiment where the user gets a token. The technique in FIG. 2A performs the process using a system of several devices. The system includes a first channel 101 (included as part of a user agent 1101), an authentication server 202, an authentication verifier 204, an ID system 206, and a session database 208. The first channel 101 can include, for example, a website, a telephone line, and the like. In FIG. 2A, the user inputs the user ID using the first channel 101 (13). The further processing shown in FIG. 2A is completed using the system elements as shown. The token value is returned to the first channel 101 (22). In some embodiments, the token value may be an alphanumeric string. In some embodiments, the token value is a single use token. Additionally or alternatively, the token value may be time sensitive or valid for a limited period of time.

  In FIG. 2A, a user using user agent 1101 is connected to the first channel and requests a login challenge (10) from authentication service 202. The authentication service (AS) 202 erases any current user authentication credentials (11) and provides a login challenge page 12 on the user agent 1101. The user supplies the user ID or the first authentication parameter to the authentication service 202 (13). In some embodiments, the first authentication parameter can be a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof. In some embodiments, the first authentication parameter can also be specific to the type of device or channel used. In other words, in some embodiments, the user may have a first authentication parameter, which is specific to landline or mobile phones, computers or wireless devices.

  In some embodiments, using the presented user ID and authentication context (14), the authentication verifier 204 determines that the user is a valid user (15). The authentication service 202 uses the ID system 206 (16) to map the user ID to the user's global ID 17. The authentication service 202 then sends a request (18) to the session DB 208 to generate a record, which includes, for example, a user ID, a global ID, an authentication context (including channel), and a session ID. The session DB 208 generates a token value (19) and combines the token value with the provided value and the current time. Also, the session DB 208 creates a session database entry and sets its authentication status value to ongoing (19). The session DB 208 returns all of this information to the authentication service 202 (20), which uses the returned token value and time 20 to generate an authentication credential. This authentication credential indicates that the user has not been authenticated and includes a global ID, a session ID, a token value, and a time 21. The authentication service 202 sets the authentication credentials to the user agent 1101, provides the token value and instructions (22) to complete the authentication on another channel.

  The example process of FIG. 2B1 illustrates the use of user agent 2102, which can be, for example, a landline telephone. The example process of FIG. 2B2 illustrates the use of a user agent 2102, which may be a wireless device, for example. The process of supplying the token value and PIN or password or second authentication parameters in the second part of the authentication process depends on whether the user is trying to connect by phone (eg, FIG. 2B1) or portable wireless applet (eg, FIG. 2B2) Yes. In some embodiments, the user enters the supplied token value (27) and then enters the user password (29). In other embodiments, the user can enter the token value and its password in a single step. The token value associates information supplied on the user agent 1101 with information supplied via the user agent 2102. This collects and uses the supplied user identification information to complete user authentication.

  In FIG. 2B 1, the second authentication parameter is provided through the user agent 2102. In some embodiments, user agent 2102 is connected to the second channel, and in some embodiments, user agent 2102 is connected to both the second channel and the second device. In one embodiment, FIG. 2B1, when the user requests a telephone connection (25) to the second channel 102, the user dials the telephone number provided via the first channel. In some implementations, the user may dial a telephone number that is already known or provided to the user prior to the instant session. The VRU gateway 200 requests a token value (26). After receiving the token value 27, the VRU gateway 200 requests a PIN, password or other second authentication parameter from the user (28). In some embodiments, the second authentication parameter may be a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination of password or PIN instead of or in addition thereto.

  In FIG. 2B2, the user accesses the second or additional channel using the wireless portable device. In the wireless cell phone implementation, the user may be asked to enter (127) a token value and PIN or password in a single request. The user then performs the process of using the wireless device as the second device. In some of the embodiments, after the token and password are entered, any subsequent process is the same, which is the phone or wireless mobile device as the second device that the user is connected to the second or additional channel. It doesn't matter whether you are using it or not.

  2B1 and 2B2, the authentication service 202 requests session data from the session DB 208 based on the input token value (30). The session DB 208 uses the token value (31) to acquire the entry creation time, user ID, global ID, authentication context (including the original channel), session ID and authentication status (eg, in progress) and return to the AS 202. To do. AS 202 verifies the session entry token, time and authentication status (32). This obtains the user ID (33) and requests that the authentication verifier 204 authenticate the user ID, PIN and authentication context (34). In some embodiments, the PIN is a channel specific PIN (see, eg, FIG. 2B2). If the authentication is successful (35), the AS 202 sends a display to the session DB 208 to update the authentication status (36) in the session database entry, for example to an authenticated session 37. In some embodiments, the session DB 208 may set an authentication status for the authentication upgrade (85). When the authentication status is updated, the session DB 208 returns it to the AS 202 (38). The user is informed that authentication is successful and the session can be continued on the user agent 1101.

  In FIG. 2C, the user returns to the first channel and requests the end of authentication with authentication credentials (40). The authentication service 202 obtains the time since the authentication credential was delivered together with the token value, global ID and user request (41). AS 202 requests that session DB 208 obtain a session database record associated with the supplied token value (30). The session DB 208 returns a session database record 931), which includes, for example, user ID, global ID, authentication context, token value, session ID, generation time, and authentication status.

  The authentication service 202 verifies the time, authentication status and global ID (42) and sends the updated authentication status to the session DB 208 (43), which updates the authentication status in the session database 208 (44). Complete the authentication upgrade. The session DB 208 returns the updated status to the AS 202 (45). A complete authentication credential 46 is created and returned to the user agent 1101 (47). The user is notified that authentication is complete and may proceed.

  In some embodiments, a reserved multi-channel authentication method allows a single user to access a resource by increasing the user's authentication level via multi-channel, where access to the resource is Requires a second authentication parameter. In some embodiments, additional authentication parameters are required on the second or additional channel. The second or additional authentication parameters can be supplied from a second device connected to the user.

  In the first embodiment of accessing the requested resource, the user performs a conventional authentication process at the website by entering their ID and password at the login page. In other embodiments, the user may be authenticated using a multi-channel authentication process. After logging on to the website, the user navigates the website at the first resource access level. If a user requests maneuver or resource and this resource requires a higher authentication access level, the user is directed to a page that provides a token value. The page then directs the user to user agent 2102, which provides additional authentication parameters. This can be connected to the second channel 6 or the additional channel 7.

  The user selects the second channel 6 or an additional channel 7 (eg a telephone) and dials a predetermined number. In other embodiments, the user may access the second channel through a mobile device, mobile phone or other web channel. The user enters the token value via the second channel and supplies a second or additional authentication parameter, such as a hard token, an answer to a security question or a voiceprint. Authentication parameters entered on the telephone channel are verified. The supplied token value serves to link to the session on the first channel (eg web). When the user completes the necessary processes, the user session on the first channel 5 is enhanced to a higher authentication access level.

  In some embodiments, the user has been authenticated on all channels and these are authenticated because the user has provided authentication parameters reliably and independently via two or more separate channels (eg, web and phone). You may go on to another channel. Thus, the phone or second channel 6 connected to the user agent 2102 can have the same level of authentication as the web or first channel 5 connected to the user agent 1101.

  FIG. 3A shows a user (50) requesting access to low-level resources. The resource again guides users who are not authenticated to conventional authentication (51). The user is challenged by the authentication service (AS) 202 (12) and supplies its user ID and password (54). The AS 202 sends the user ID, PIN and context to the authentication verifier 204 (55), which verifies the user personal information and password (35). AS 202 then requests that ID system 206 map (16) the user ID to its global ID (17). The AS 202 generates a low value resource authentication credential (59), and the AS 202 returns this credential to the user agent 1101 (60). The user immediately has full access to the low value resource 303.

  If the user later requests a higher value resource 307 in the session (63), the user needs stronger authentication credentials (64) to access this resource. The user is again guided by AS 202 (65) to obtain stronger authentication credentials. After the user displays a request for a stronger authentication credential (66), the AS 202 acquires the request for the user ID and session DB 208 (33) and generates a record (18), which records the user ID, global ID. , Authentication context (including channel) and session ID. The session DB 208 generates a token value (19) and combines the token value with the other supplied values and the current time. In some implementations, the session database 208 also generates a session database entry (19) and sets its authentication status value to in progress. The session DB 208 returns all of this information to the AS 202 (20), and the service uses the data to update the current user authentication credentials with the token value and time (71). The AS 202 sets authentication credentials on the user agent 1101 (22) and provides the user with a token value and instructs them to complete an additional authentication step on another channel.

  The method in FIGS. 3B1 and 3B2 is similar to FIGS. 2B1 and 2B2. The second authentication parameter used to accomplish this higher level resource access requirement may be a password in some embodiments. In other embodiments, the second authentication parameter may be any suitable second factor, including a wireless applet, voiceprint, phone-only PW, soft token or hard token. In an alternative embodiment, FIG. 3B3, the user may use a telephone channel as the second channel and a voiceprint as the authentication parameter. In this example, AS 202 sends a request for voice phase to voice authentication verifier 303 (132). The voice authentication verifier 303 sends the voice phase XXX to the AS 202 (133), and the service requests that the user say XXX. The user then reacts by 135 saying XXX and the specified voice phrase XXX is sent to the voice authentication verifier 303 which authenticates the user ID, the user voice and context of the phrase XXX (136). . Then, the voice authentication verifier 303 sends a notification that the authentication is successful to the AS 202 (35). AS 202 sends the updated authentication status to session database 208 (36), which sets the authentication status as an authentication upgrade (82). The updated status message is then sent to the AS 202 (38), which requests that the user continue the session on the user agent 1101 (39).

  Alternatively, the user may continue their user session on either the first and second channels, and the authentication strength is considered the same on both channels once the user completes the authentication procedure. 3B4-3B6, AS 202 generates an authentication credential (88) for use on the second channel. AS 202 may then request that the user continue the session on user agent 1101 (39), but the user may also continue the session on user agent 2202 (90).

  In FIG. 3C1, after the user completes the authentication step on the second channel (ie, user agent 2102), the user returns to the first channel and requests an authentication upgrade completion (98). AS 202 requests a session database record associated with the supplied token value (30). The session DB 208 returns a session database record (31), which may include, for example, a user ID, global ID, authentication context, token value, session ID, generation time, and authentication status. The authentication service 202 authenticates the time, authentication status, and global ID 91 and sends a display (43) to the session DB 208, which updates the authentication status in the session database 208 to completion of the authentication upgrade (44). Then, the session DB 208 transmits the updated status to the AS 202 (45). An upgraded authentication credential is then generated (94) and returned to the user agent 1101 (95). The user is redirected (96) and returned to access the requested higher level resource. In another embodiment (eg, FIG. 3C2), the user completes the authentication process on either the first or second channel. In FIG. 3C2, the user requests a channel authentication upgrade for higher level resources on both the first and second channels (99). After the credentials are established for both channels, the user can continue to complete the authentication process as shown in FIG. 3C1.

  Processes that require higher levels of access authentication credentials can be repeated for many types of high level access resources that are required as higher value resources are required. Furthermore, additional factor authentication for higher level resource access is required at the first login and cannot be delayed until the higher level resource is actually requested.

  Some embodiments may also incorporate device registration. Device registration ensures that an authenticated user can register a specific device for high-level resource access, so that if a user requests access to high-level resources in the future, the device registration You are not required to supply two authentication parameters.

  In FIGS. 4A1 and 4A2, the user performs the same process as shown in FIG. 3A. However, after the ID system 206 returns the global ID 17, the AS 202 requests a strong authentication method for the user ID (142), and the ID system 206 returns a reliable device registration (143). AS 202 determines whether the user is registered for a secure device credential 144, whether a secure device credential exists 145 and the current device security credential user ID entered by the current user. It can be determined 146 whether the user ID matches.

  FIG. 4A1 illustrates one embodiment where there is no secure device credentials. In FIG. 4A1, after AS 202 determines that there is no reliable device credential 145, AS 202 generates (59) a low level resource credential and gives the user an authentication credential for the low level resource. (60). The user then performs the same process of FIG. 3A to request and access a resource, which requires a second or additional authentication parameter. Further, in some embodiments, the AS 202 may contain a secure device registration with an authentication credential that includes a token value and time (70).

  In FIG. 4A2, a secure device credential exists but does not match the current user ID 146. In this embodiment, AS 202 generates an authentication credential for the first authentication level (59) and provides the authentication credential while deleting the device security credential (60). The user then requests the resource by performing the same process of FIG. 4A1, but this resource requires a second or additional authentication parameter.

  In FIG. 4A3, a secure device credential exists and matches 146 the current user ID. In this example, AS 202 generates a high value authentication credential 68, which is for resources that require additional or second authentication parameters. AS 202 then provides high-level authentication credentials to user agent 1101. The user can then access resources that require additional or second authentication parameters, but need not supply additional or second authentication parameters via the second channel.

  4B1-4B3 is similar to the embodiment shown in FIGS. 3B1-3B3, but in the embodiment shown in FIGS. 4B1-4B3, the authentication verifier 204 authenticates to AS202. After indicating that has succeeded (35), the AS 202 determines whether reliable device registration is required (137). If secure device registration is requested, the AS 202 sends a request to the user agent 2102 asking if you want to register the device connected to the user agent 1101 as a secure device over time (138). Then, the user indicates that he does not want to register the device (139). The session database 208 sets the authentication status to authentication upgrade and sets reliable device registration for a long time (141). The updated status is returned to the AS 202 (38) and the service requests that the user continue the session on the user agent 1101 (39). In some embodiments, the device connected to the first device or user agent 1101 may be registered as a long-term secure device forever. In some embodiments, the device may be registered for the current session, and in some embodiments, the device may be for a limited time or a specific number of user sessions, logins or requests for resources. May be registered. In FIG. 4B1, the user can call the second channel / device, in FIG. 4B2, the wireless / mobile phone applet can be the second channel / device, in FIG. 4B3, the phone is the second channel / device, and If the user's voice can be an authentication parameter, it may be asked if secure device registration is required.

  In FIG. 4C, if control is returned to the first device via the first channel, AS 202 generates a persistent credential upon confirming the device registration in the session data (169). Identifies the type of credentials that were possible for the owner and the first device. The AS 202 also upgrades the authentication credentials (94), and then the updated authentication notification (171) and the authentic device credentials are returned to the user agent 1101. Thereafter, if the user requests a high value resource via the user agent 1101 (96), the resource request is successful 97.

  Next, when upgrade authentication is requested from the AS 202, the credentials may be a persistent cookie in some embodiments, but are discovered and examined. And if the user and device are registered for secure access to the requested resource, the upgrade is then completed and there is no return to the second or additional channel (eg, FIG. 4A3).

  Figures 5A1-5C show different but related examples of how an authenticated user or a second user can see an indication of approval to a third party or first user who is authenticated and behaves as a registered user. It is possible to provide it. In some embodiments, the first user only has access to the second user's account, and in some embodiments, the first user has access to resources that require an indication of approval. A third party can access at least some of the registered user's resources, in which case the registered user does not expose personal authentication information to the third party user. In some embodiments, the first user who wants to access an account or resource is not known to the resource provider, and in some embodiments the first user does not have an account with the resource provider. Also good. In some embodiments, the first user is connected to the user agent 1101 and the single registered user is connected to the user agent 2102. In some embodiments, the process associated with user agent 2102 may be performed by N different registered / authenticated users, all of which are authenticated or access the requested resource first. Provide an indication of approval to the user.

  In FIG. 5A1, the first user requests access to the registered user's account. FIG. 5A1 is the same as FIG. 2A described above. However, in FIG. 5A1, the second user, here the account owner / registered user, provides the first authentication parameter to the relevant third party / first user, which in one embodiment includes the user ID. But you can. The first authentication parameter given to the first user can be, for example, a descriptive title, an identification number, or an SSN. The third party user enters the user ID on the first channel (13). The AS sets authentication credentials on the user agent 1 (22) and the first user is given a token value and instructed to complete authentication on another device / channel. The first user can send the token value to a second user or a registered user connected to the user agent 2102.

  The second user connected to the user agent 2102 in FIG. 5B1 accesses the system via a different device on the same channel in the second channel or alternative embodiment. In some embodiments, the second user enters a token value (27) and a second authentication parameter (29), which in one embodiment can be a password or PIN. Alternative or additional examples of the second authentication parameter may be a user ID, descriptive title, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof. The second user can then perform the process shown in FIG. 2B1.

  Some embodiments further protect the personal information of registered users. In FIG. 5A2, the relevant third party or first user accesses the web page 121 (120), where the user enters personal descriptive information, such as its name or job (122). Examples of personal descriptive information may include financial advisors, brokers, doctors, tax payers or spouses in some embodiments. In some embodiments, the requested resource may be authentication of the first user, in some embodiments the resource is information that is limited or requires approval of the second user, In an embodiment, the resource may be a registered user or second user's personal account or information, or access to authorization to complete a transaction. In FIG. 5A2, AS 202 generates a record 18, which contains user information, access context and channel information. The session database 208 generates a token value, sets the current time, and sets the authentication status to ongoing (19). After the session database 208 returns the token value and time to the AS 202 (20), the AS generates an authentication credential, token value, and time that reflects that the user is not authenticated (124). The first user is given a token value to communicate to the registered user (72).

  After receiving the token value and the request to complete the authorization process on the second channel, the registered or second user authenticates himself in some embodiments. The second user may authenticate himself / herself by a conventional authentication process, and in other embodiments the second user authenticates himself / herself using the multi-channel process shown in FIGS. Also good. The second user may then access an alternative or second channel that challenges the user for the token value (26). In FIG. 5B2, after the AS 202 validates the token, authentication, context, time and status 251, the second user is given descriptive information entered by a third party (251). If satisfied, the second user can authorize the third party user's access (252). Upon receiving an authorization indication from the second user, AS 202 updates the authorization status and session DB 208 updates the session record and sets the authorization 36 status to the authorized status (255). The updated status is returned to the AS 202 (38), which requests that the second user inform the first user that the first user may continue the session on the user agent 1101 (154). As already mentioned, in FIG. 5C, the third party user continues on the first channel and is given authentication credentials that this user is a registered user.

  5A2 and 5B2, none of the second (registered) user's authentication information is exposed to a third party, but this is because the second user holds the password or authentication parameter from the first user and the second channel. This is because it is permitted to input the authentication parameter via The second user's user ID or other first authentication parameters in alternative embodiments may be exposed, but the second user's password or second authentication parameters are not exposed. In some embodiments, the second user ensures that the account is later secure from unauthorized access by the first user and that its authentication information is not publicly distributed. However, the authorization context may allow the first user's access to the second user's personal information, financial and other sensitive material and information. Thus, the first user can access the account information of the second user or registered user, but the exposure of the second user's authentication parameters is limited.

  In FIG. 5C, after the second user enters the second authentication parameter on the second device (connected to user agent 2102), the first user is on the first channel connected to user agent 1101. (See, eg, FIG. 2C), the authentication credentials are given as if the user were the account owner.

  In FIG. 6, a registered user can access a third party session authorized or authenticated by the registered user and terminate the session if desired. In other embodiments, the second (registered) user may upgrade or downgrade the first user's access to the resource or multiple resources. In some embodiments, a registered user connected to user agent 2102 requests to connect to a resource (25), which determines the status of the session associated with the first user. The system then requests a token value and an authentication parameter (26), which may be a channel specific PIN (29) associated with the user. After the registered user enters the token value and its password, the back end system updates (36) the status indicated by the second user by updating the authentication status of the user session associated with the first user. Reflect 126. In some embodiments, the situation may be a terminated session, and in other embodiments the situation may be a session downgrade or upgrade. The second user is notified that the first user's session has been terminated (128). In some embodiments, the second user is notified that the first user's access has been upgraded or downgraded. The situation is maintained with session data associated with the session ID of the third party user (127). Next, when the third party user requests a resource (129), the termination status 130 is detected and the third party user session is terminated (131). In some embodiments, an upgrade or downgraded situation of the first user's session may be detected, and the first user's session is modified appropriately and the second user (account owner / registered user). ) Reflect the new situation set by.

  In similar and related embodiments, FIGS. 7A1-7C1 and FIGS. 7A2-7C2 provide session width and transaction specific access to resources requested by a minor and child account owner whose parent is otherwise restricted. Show how to provide access authorization. FIG. 7A3 also shows means for providing a joint account type authorization facility for a number of resources that require user authorization.

  In one embodiment, the first user authenticates himself but still requires an authenticated second user to authorize the first user's session. In FIG. 7A1, the first user, here a minor child, has an account and is logged in and navigates to low level resources. The embodiment shown in FIG. 7A1 is similar to the embodiment shown in FIG. 3A. However, if the child requests resource 307 in FIG. 7A1 (63) and this resource requires stronger authentication parameters (eg, parental approval), then the high level resource verifier 305 requires parental approval. (87). In some embodiments the resource can be a change in personal data, in other embodiments the resource can be a limited access website, or in other embodiments the resource can be a requested transaction. Can be. The high level resource verifier 305 guides the first user (65) to complete the processes necessary to access the limited resources. The minor is given the token value and instructions (72) to communicate the token value to the second user, the parent of the minor, and allow the parent to access the minor.

  In another embodiment, the first user authenticates himself but still requires the second user to authorize the first user's access to the requested resource. FIG. 7A2 shows an example where the first user, here the minor, tries to complete the transaction, but the minor does not have the authentication credentials required by the resource. In some embodiments, minors can access lower level resources without higher value credentials. If the minor requests a higher level resource 307 (63) and this resource requires parental approval, the AS 202 recognizes that the first user request requires parental approval to complete ( 87). In some embodiments, this approval may be given by any second user, but this user is authorized to approve the first user's request for a resource, such as a teacher or supervisor. AS 202 directs session database 208 to generate a transaction record (67), which includes the user ID, global ID, transaction details, channel, parental approval, and session ID. The session database 208 sets the authentication status by erasing the transaction ID record for user ID 1, session ID 1, and sets the authentication status as user 1 (first user) as open or approved in an alternative embodiment. (56). Further, the session database 208 generates a transaction ID value, sets the current time, and sets the authentication status as an open status (57). The minor is redirected back to the AS 202 (65) to obtain stronger authentication credentials, in this example parent approval. AS 202 obtains the user ID (33) and requests from session DB 208 (18) generates a record (31) This record includes, for example, user ID, global ID, transaction details, channel, parental approval and session ID . The session DB 208 retrieves the last transaction ID and session ID 58 for user ID1, generates a token value (69), and combines the token value with the other values supplied and the current time. The session database 208 can also generate a session database entry, setting its authentication status value to in progress, or in some embodiments, to an in-progress transaction ID. The session DB 208 returns this information to the AS 202 (20), and the service uses this information to update the current user authentication credentials with the token value and time (71). AS 202 sets the authentication credentials on user agent 1101 and provides a token value to user agent 1101 (72), which informs the parent to complete additional authentication steps on other channels. Provided with instructions, this channel may be, for example, a user agent 2102. In some embodiments, the first user is instructed (72) to inform other joint account holders to authorize the transaction on other devices / channels (eg, FIG. 7A3).

  After completing the process shown in FIG. 7A1 or 7A2, the minor communicates the token value to the parent and asks the parent to indicate approval for minor access to the resource. In some embodiments, FIG. 7B1, the parent authenticates itself. In some embodiments, the parent or second user may authenticate themselves using a conventional single channel method, while in other embodiments, the parent / second user uses a multi-channel method. May authenticate themselves, and in some embodiments the method may be similar to the method shown in FIGS. In this example, the parent is connected to the user agent 2102 but requests parent authorization 78.

  In FIG. 7B1, the parent may use the telephone as the second channel. In some embodiments, the parent or second user may use a computer or a wireless device such as a mobile phone, portable computing device, PDA or Blackberry device. The authentication service 202 requests session data from the session DB 208 based on the input token value (30). The session DB 208 uses the token value to obtain and return a database record (31), which is the entry creation time, user ID, global ID, authentication context, token value, session ID, time, channel, parent of the session Approval and authentication status to AS 202 are included. In some embodiments, the session DB 208 may return an indication that requires approval of the session's parent (174). AS 202 verifies the token and time (80). The ID system 206 confirms that the second user is an “authorized parent” for the first user (147, 148). If the second user is an authorized parent, AS 202 provides the user agent 1101 with information about the first user (149) and the second user authorizes access to the requested resource of the first user. Request. After verifying the information of the first user, the parent authorizes the request (150), and the AS 202 updates the authorization status (36). The session DB 208 updates the authorization status with the parent authorization upgrade and the parent authentication information 152 and notifies the AS 202 that the status has been updated (38). AS 202 requests (22) that the session be completed on the first channel connected to user agent 1101. In some embodiments, the AS requests (154) that the second user informs the first user to continue the session on the first channel.

  In FIG. 7B2, after ID system 206 confirms that the second user is an “authorized parent” for the first user (147, 148), AS 202 requests permission to proceed with the transaction (177). To do. After the second user grants permission 178, AS 202 requests a transaction database record (transaction ID) from session database 208 (179). The session database 208 provides transaction details 180 through the AS 202, which passes the transaction details to the second user (181) and asks the second user to approve the transaction. After verifying the transaction details, the second user indicates their approval (150) and the AS 202 updates the approval status (36). The session DB 208 sets the authorization status to transaction and parent authorization upgrade for parent authentication information 185. In addition, the session status is marked as parental approval, the transaction record reflects the transaction ID, and an appendage of the record containing the second user's authentication information is generated. An updated status message is sent to the AS 202 (38), which requests that the second user inform the first user that the session may continue on the user agent 1101 (154).

  In FIG. 7C1, after the second user (parent) authenticates or authorizes the request for the first user's (minor) resources, the first user may continue the session (155) on the first channel / device. . The AS 202 obtains the token value, the global ID, and the time since the authentication credential was distributed along with this user request. Using the token value, AS 202 requests session DB 208 to obtain a session database record associated with the supplied token value (30). Session DB 208 returns a session database record (31), which in some embodiments includes user ID, global ID, authentication context, token value, session ID, creation time, channel, and authentication status. The authentication service 202 verifies the time, authentication status and global ID (91) and in some embodiments confirms that there is a parent approval 159 for the session. In other embodiments, other forms of approval may be verified. The AS 202 uses the session DB 208 to update the authentication status in the session database to parent authorization upgrade completion (161) (43). In some embodiments, the authentication status may be updated to reflect the completion of joint approval. AS 202 then reflects the upgraded authentication credentials, which in some embodiments may reflect the parent's approval, and in some embodiments (FIG. 7C2) reflects the strength upgrade 187. You don't have to.

  In FIG. 7C1, the upgraded authentication credential includes an indication of parental approval in some embodiments, but is formed (163) and returned to the user agent 1101 (95) The first user returns again. (96) to access higher level requested resources (97).

  In some embodiments, FIG. 7C2 will follow FIG. 7B2. After AS 202 generates an updated authentication credential 187, this credential does not include a strength upgrade in this example, but the updated authentication credential and transaction ID are returned to the first user ( 188). The first user requests a high value resource (189) and supplies a transaction ID, which is used to retrieve the transaction record (190). The session database 208 returns a transaction record (191) that is verified for parental approval (192) or, in some embodiments, returns another form of approval, and transaction details are posted (193). ). Resource verifier 306 then updates the transaction record in session database 208 (194), which records the status as a transaction complete 195. The first user 101 is informed that the transaction has been completed (97). The transaction is completed because the second user 102 or parent's electronic signature and transaction details authorizing the transaction are obtained during the authorization process and the transaction is allowed to be executed.

  In FIG. 7A3, the holder of the joint account attempts to conduct the transaction, and this transaction requires the approval of both account participants. After the transaction application generates the electronic signature request record and sets it in the session database 208, it directs the user back to the authentication service 202. In some embodiments, the record includes user ID, global ID, transaction details, channel, joint approval for the transaction, and session ID. The authentication service 202 creates a joint user session database entry, which is referred to as a signature request entry. The entry includes a session ID and signature status, and further includes an indication that the first user has been approved. The token value created for this entry is returned to the first account holder along with an instruction to complete the approval process for the second account holder.

  The second account holder is connected to the user agent 2102 but logs on to the system and steers the token value to the required location. The electronic signature request is presented with a display of the requested transaction details (eg, FIG. 7B3). The second user approves the transaction and informs the first user that the first user may complete the transaction 154.

  In FIG. 7C3, the first user continues in an embodiment similar to FIG. 7C2. However, in this example, AS 202 looks for joint authorization 329 for the transaction, the transaction record is electronic signature record 335, and the requested resource is a joint authorization for the transaction secured by the electronic signature. This allows the electronic signature transaction to be extracted from the session database 208 and presented to the executing application. The user is notified of the completion of the requested transaction.

  Another embodiment of the multi-channel method includes a requested credit card transaction. In the first embodiment, the user requests that the credit card issuer contact the user via a specific device for all transactions that exceed a certain dollar amount. If the card is stolen and the transaction amount entered for authorization exceeds the limit specified by the user, the user is contacted via the device selected by the credit card issuer back-end system and the ID and credit You are asked to provide a certificate or other authentication parameter. The request for this authentication parameter may be made at the point of purchase or in some embodiments at the point of sale, and in other embodiments the credit card back end system may be credit card You may contact the account owner. The back end system authorizes transactions only after the credentials are validated.

  In another embodiment, credit card transactions may be authorized or authenticated using multi-channel. In the first embodiment, this includes, for example, credit card service 401, credit card authority 402, AS 202, authentication verifier 204, ID system 206, and session database 208.

  In FIG. 8A, a business partner connected to user agent 1101 attempts to trade using a credit card instead of a credit card owner. In this example, the credit card service requires verification (410) for the transaction, if the transaction is greater than the previously determined allowed limit 412. Credit card authority 402 sends an authorization process to AS 202, authentication verifier 204, ID system 206, and session DB 208, which creates a record and creates session 422 with token value and time. The user is instructed 424 to invoke and authorize the transaction.

  In FIG. 8A, the first user sends a request (410) to the credit card authority 402 at the point of sale, which may be, for example, a credit card reader. Credit card authority 402 determines whether the amount is greater than a predetermined limit 412. If the amount requested for the transaction is greater than the predetermined limit, the credit card authority 402 then retrieves the user ID 413 and global ID 16 and credit card number for the global ID and user ID for the ID system 206. To map. The ID system 206 returns the global ID and user ID 58 'to the AS 202, and the service then creates a transaction record 414. The transaction record includes user ID 1, global ID 1, transaction details, credit card processor ID, channel 1 and credit card authorization for the transaction. Next, the session DB 208 sets the authentication status 415 by deleting the credit card transaction ID for user ID1, setting the credit card processing device ID, and setting the authorization status to credit card disclosure. Done. Next, the credit card authority 402 requests the AS to create a record (418), which includes a credit card number, a credit card transaction ID, a global ID, and a user ID 418. After creating the record 419, the session DB creates a token value and sets the authentication status to ongoing 412. The session DB 208 then returns the token value and time (70) to the credit card authority 402, which creates a session associated with the token value 422 and prompts the credit card service, and then on the second channel. The user (423, 424) is instructed to authorize a transaction related to the token value. In some embodiments, the credit card reader may use a telephone or telephone line as the second channel. In some embodiments, a credit card owner or a second user connected to the user agent 2 may authorize the transaction using a computer or wireless device.

  In some embodiments, a call to authenticate or authorize a transaction may be initiated by a credit card company. In some embodiments, the credit card company records a telephone number and calls a second user when the transaction is made, which transaction requires additional authentication or authorization.

  In FIG. 8B, the merchant passes the token to the credit card holder and requests to complete the authorization process. In some embodiments, the credit card holder or the second user may authenticate themselves by a conventional authentication process on additional channels, while in other embodiments the second user uses a multi-channel process. Although this may authenticate itself, this process may in some embodiments be similar to the process shown in FIGS. In some embodiments, the second user or credit card holder may authenticate himself on a second channel connected to user agent 2102. The second user may authenticate himself on the channel connected to the user agent 2102, but in some embodiments this is done by entering a token, user ID and password, instead of This is done by entering second and / or additional authentication parameters in this embodiment. The second user is currently connected to the second channel, but then performs a process similar to the process shown in FIG. 7B2. In this example, parental approval is not required, but the second user must be authorized to conduct a credit card transaction (427), and approval for the credit card transaction is required. Both authorizations and authorizations are stored by the back end system in the credit card transaction record 432. After the second user approves the transaction (434), the status of the session associated with the requested credit card transaction is updated (86). The second user is then instructed to inform the first user or business partner that the transaction is complete (154).

  At 8C, the second user completes the transaction if the authentication parameters entered by the second user or credit card account owner are verified. In some embodiments, the second user can proceed with an approval for the transaction. Credit card authority 402 provides authorization, token value and credit card number to AS 202, and the service requests database records (30). Session DB 208 returns a database record (31), which includes the user ID, global ID, authentication context, token value, session ID, time, channel, credit card transaction approval and status. AS 202 then verifies the session DB record and determines that the credit card owner has approved the transaction (39). The updated authentication status 36 is then returned to the session DB 208, which sets the authentication status to credit card transaction approval completion (440). The updated status is then returned to the AS 202 (38) and the approved credit card transaction ID 441 is returned to the credit card authority 402. The credit card authority verifies the credit card account holder's approval (444) and posts the transaction details (445). The credit card authority 402 then updates the credit card transaction record in the session DB 208 (446), and the database records the new situation as a credit card transaction completion 447. After the status is updated, the credit card authority sends a notification (401) and receipt of the completed transaction to the credit card service 401, which then connects the end user connected to the user agent 1101. Information is sent to (449).

  The techniques described above can be implemented in digital electronic circuitry, computer hardware, firmware, software, or combinations thereof. An embodiment may be a computer program product, for example a computer program that is explicitly embodied in an information carrier such as a machine readable storage device or a propagated signal, which is executed by a data processing device or Controls the operation of the device, which is for example a programmable processing device, a computer or a number of computers. A computer program can be written in any form of programming language, including any language that has been edited or interpreted, and the program can be implemented in any form, which can be a stand-alone program or module, component , Subroutines and other devices suitable for use in computing environments. The computer program is executed and executed on one computer or multiple computers provided at one location or distributed at multiple locations and interconnected by a communication network.

  The method steps can be performed by one or more programmable processing devices that perform the functions of the invention by executing computer programs to operate on input data and generate output. Also, the method steps are performed by a specific purpose logic circuit configuration, and the apparatus can be implemented as this configuration, but the circuit configuration can be, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated circuit). A module can be a processing unit / special circuitry that implements a portion and / or functionality of a computer program.

  Processing devices suitable for the execution of computer programs include, for example, both general and special purpose microprocessors and any one or more processing devices of any kind of digital computer. Generally, a processing unit receives instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processing device for executing instructions and one or more memory devices for storing instructions and data. Generally, the computer also includes or is operably connected to one or more mass storage devices for storing data in order to receive data and / or transfer data. For example, a magnetic, magneto-optical disk or optical disk. Also, data transmission and instructions can occur via a communication network. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, eg semiconductor memory devices such as EPROM, EEPROM and flash memory devices; internal hard disks or removable Includes magnetic disks such as disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

  As used herein, the terms “module” and “function” refer to, but are not limited to, software or hardware components that perform a task. The module is advantageously configured to reside on an addressable storage medium and may be configured to execute on one or more processing devices. A module may be fully or partially implemented in a general purpose integrated circuit (“IC”), FPGA, or ASIC. Thus, modules are, for example, software components, object-oriented software components, class components, task components and other components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, micro-controllers, etc. Codes, circuitry, data, databases, data structures, tables, arrays, and variables may be included. The functionality provided in parts and modules may be combined into fewer parts and modules, or further separated into additional parts and modules. In addition, the components and modules may be advantageously implemented on many different platforms, such as computers, computer servers, application-capable switches or data communication infrastructure devices such as routers, or public or private telephone switches or Includes telecommunication infrastructure equipment such as private branch exchanges ("PBX"). In any of these cases, embodiments may be achieved by either writing the native application for the selected platform and connecting the platform to one or more external application engines.

  In order to provide user interaction, the above techniques can be implemented on a computer having a display device that provides information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor. Display device, a keyboard and a pointing device such as a mouse or trackball, which allows the user to provide input to the computer (eg, interaction with user interface elements). Other types of devices can also be used to provide interaction with the user; for example, feedback to the user can be any form of sensory feedback, such as visual feedback, auditory feedback or tactile feedback. Input from the user can be received in any form, including acoustic, speech or haptic input.

  The techniques described above can be implemented in a distributed computing system, which includes back-end components such as data servers and / or middleware components such as application servers and / or front-end components, For example, a client computer and / or web browser with a graphical user interface, which allows the user to interact with the embodiment, or any combination of these back-end, middleware or front-end components including. The components of the system can be interconnected by any form or medium of digital data communication, eg, a communication network. Communication networks, for example, also referred to as communication channels, include local area networks (“LAN”) and wide area networks (“WAN”) such as the Internet, and include both wired and wireless networks. Unless explicitly indicated otherwise, a communication network may also include all or part of a PSTN, eg, part owned by a particular carrier.

  The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The client and server relationship is caused by a computer program running on each computer and having a client-server relationship with each other.

  The invention has been described with reference to specific embodiments. The alternatives described here are merely illustrative and do not limit the alternatives in any way. The steps of the present invention can be performed in a different order and still achieve desirable results. Other embodiments are within the scope of the following claims.

Claims (72)

A multi-channel method that allows users to access resources,
Authenticate the user;
Receiving a request for a resource requiring a second authentication parameter via the first channel;
Sending a token value via the first channel;
Receiving the token value and the second authentication parameter via a second channel;
Associating a request received via the first channel with a second authentication parameter received via the second channel using the token value; and based on the association of the request to the second authentication parameter Enabling or disabling the user's access to the. The resource requires the second authentication parameter and at least one additional authentication parameter;
Receiving the token value and at least one additional authentication parameter via at least one additional channel; and using the token value to at least one additional authentication parameter received via at least one additional channel. The method of claim 1, further comprising associating the request received over a channel.   The method of claim 1, further comprising providing the resource via the first channel. Receiving a request for additional resources via the first channel that requires at least one additional authentication parameter;
Receiving the token value and at least one additional authentication parameter via at least one additional channel; and using the token value to at least one additional authentication parameter received via at least one additional channel; The method of claim 3, further comprising associating the request received via a first channel.   The method of claim 4, wherein at least one additional authentication parameter is the second authentication parameter.   The method of claim 1, wherein authenticating a user includes receiving a first authentication parameter from a first device over a first channel, wherein the first device is connected to the user.   The method of claim 6, wherein the first authentication parameter is a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof.   The second authentication parameter according to claim 6, wherein the second authentication parameter is not the first authentication parameter.   The second authentication parameter of claim 6, wherein the second authentication parameter requires more than the first authentication parameter.   The method of claim 6, wherein the first authentication and the second authentication parameter are channel specific.   The method of claim 4, wherein the additional authentication parameter is not the first authentication parameter or the second authentication parameter.   The method of claim 4, wherein the additional authentication parameter requires more than either the first authentication parameter or the second authentication parameter.   5. The method of claim 4, wherein the additional authentication parameter is a user ID, password, partial password, hard token, soft token, wireless applet, voiceprint, or any combination thereof.   The method of claim 4, wherein at least one of the additional channels is the second channel.   The method of claim 1, further comprising providing the resource via the first channel and the second channel simultaneously.   The method of claim 1, wherein the first channel is a telephone line, a wireless connection or an online connection.   The method of claim 1, wherein the second channel is a telephone line, a wireless connection or an online connection.   The method of claim 1, wherein the second authentication parameter is a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof.   The method of claim 1, wherein authenticating a user includes using a multi-channel authentication process or a single channel authentication process.   Further comprising generating a credential wherein information associated with the credential is provided to the first device without the resource being provided with a second authentication parameter via the second channel. The method of claim 1, wherein the method is indicated.   21. The credential of claim 20, wherein the credential includes a permanent credential, a time sensitive credential, a credential that expires after a predetermined number of user sessions, or any combination thereof. In a method where the user tries to leave the first session and start a new session,
Authenticate the user;
Receiving a request for the resource from the first device via a first channel, wherein access to the resource requires the second authentication parameter provided via the second channel; and associated with the credential 21. The method of claim 20, comprising processing the information.   The information related to the credential supplies the resource if the resource indicates that the second authentication parameter is supplied to the first device without being supplied via the second channel. 23. The method of claim 22, further comprising: A method for using multi-channel to authenticate a user to allow said user access to a resource, comprising:
Receiving a first authentication parameter from a first device associated with the user via a first channel, wherein the user is not authenticated;
Send the token value;
Receiving the token value and the second authentication parameter from a second device via a second channel, wherein the second device is connected to the user;
Using the token value to associate the first authentication parameter with the second authentication parameter; and enabling or disabling the user based on the association of the first authentication parameter to the second authentication parameter. A method comprising:   25. The method of claim 24, further comprising authenticating the user based on the first authentication parameter and the second authentication parameter.   The method of claim 24, further comprising notifying the user that the authentication is complete via the second channel.   25. The method of claim 24, further comprising causing the user to continue a user session on the first channel.   25. The method of claim 24, wherein the first channel is a telephone line, a wireless connection or an online connection.   25. The method of claim 24, wherein the second channel is a telephone line, wireless connection or online connection.   25. The method of claim 24, wherein the first authentication parameter is a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof.   25. The method of claim 24, wherein the second authentication parameter is a user ID, password, hard token, soft token, wireless applet, voiceprint, or any combination thereof.   The method of claim 24, wherein the first authentication parameter and the second authentication parameter are channel specific.   25. The method of claim 24, further comprising receiving the token value and at least one additional authentication parameter via at least one additional channel.   The additional authentication parameters include a user ID, a password, a partial password, a part of the first authentication parameter, a part of the second authentication parameter or a combination of the first and second authentication parameters, a hard token, a soft token, a wireless 34. The method of claim 33, wherein the method is an applet, voiceprint, or any combination thereof.   34. The method of claim 33, further comprising associating the first authentication parameter, the second authentication parameter and at least one additional authentication parameter using the token value.   34. The method of claim 33, further comprising authenticating the user using the first authentication parameter, the second authentication parameter, and at least one additional authentication parameter.   34. The method of claim 33, wherein at least one of the additional channels is not the first or second channel. A method that allows users to access resources using multi-channel,
Receiving a first authentication parameter from a first device, wherein the first device is connected to a first user;
Receiving a request for a resource from the first user, wherein the resource requires an indication of the approval of the second user;
Sending a token value to the first device;
Receiving a second authentication parameter and the token value from a second device, wherein the second device is connected to the second user;
Associating the first authentication parameter with the second authentication parameter using the token value; and allowing the user access to the resource based on the association of the first authentication parameter and the second authentication parameter; A method that includes making it impossible.   40. The method of claim 38, further comprising receiving an approval indication from the second user and authorizing the request from the first user.   40. The method of claim 38, wherein receiving the first authentication parameter from the first device further comprises receiving the first authentication parameter from the first device via the first channel.   40. The method of claim 38, wherein the second user is authenticated using a single channel or multi-channel authentication process.   39. The method of claim 38, wherein receiving a second authentication parameter and the token value from a second device further includes receiving a first authentication parameter from the first device via a first channel.   39. The method of claim 38, comprising associating the request received from the first device with an indication of the approval from the second user received via the second channel using the token value. .   40. The method of claim 38, comprising providing the resource to the first device.   39. The method of claim 38, wherein the first authentication parameter is a user ID, a descriptive title, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof.   40. The method of claim 38, wherein the first authentication parameter is related to the second user.   39. The method of claim 38, wherein the second authentication parameter is a user ID, a descriptive title, a password, a hard token, a soft token, a wireless applet, a voiceprint, or any combination thereof. In the method wherein the resource requires the second authentication parameter and at least one additional authentication parameter,
Receiving the token value and at least one additional authentication parameter via at least one additional channel; and using the token value to at least one additional authentication parameter received via at least one additional channel. 40. The method of claim 38, comprising associating the request received over a channel.   49. The method of claim 48, wherein at least one additional authentication parameter is associated with at least one additional user.   The additional authentication parameters include a user ID, a password, a partial password, a part of the first authentication parameter, a part of the second authentication parameter, or a combination of the first and second authentication parameters, a hard token, a soft token, 49. The method of claim 48, wherein the method is a wireless applet, a voiceprint, or any combination thereof.   49. The method of claim 48, further comprising associating the first authentication parameter, the second authentication parameter and at least one additional authentication parameter using the token value.   49. The method of claim 48, further comprising authenticating the first user using the first authentication parameter, the second authentication parameter, and at least one of the additional authentication parameters.   49. The method of claim 48, wherein at least one of the additional channels is not the first or second channel.   Generating a credential with information, the certificate including indicating whether the resource may be provided to the first device without an indication of the approval from the second user. 38. The method according to 38.   55. The credential of claim 54, wherein the credential comprises a cookie, a permanent credential, a time sensitive credential, a credential that expires after a predetermined number of user sessions, or any combination thereof. book. In the method in which the first user attempts to leave a first session and start a new session,
Receiving the first authentication parameter from the first device, wherein the first device is connected to the first user;
Receiving a request for the resource from the first device, wherein access to the resource requires an indication of authorization from the second user; and processing information associated with the credential 55. The method of claim 54.   The information related to the credential comprises providing the resource if the resource indicates that the resource is provided to the first device without the approval of the second user. Item 56. The method according to Item 56. A method of providing resources to users using multi-channel,
Authenticate the first user;
Receiving a request for a resource that requires an indication of approval from a second user from a first device via a first channel, wherein the first device is connected to the first user;
Sending a token value to the first device;
Authenticating the second user;
Receiving the token value from a second device via the second channel, wherein the second device is connected to the second user;
Receiving an indication of the approval from the second device;
Associating the request from the first device with an indication of the approval from the second device using the token value; and based on the association of the request with respect to the indication of the approval Providing a method.   59. The method of claim 58, wherein authenticating comprises authenticating using a multi-channel process, a multi-channel process, or any combination thereof.   Authenticating the first user receives a user ID and a first password related to the first user via the first channel and authenticates the first user based on the user ID and the first password. 59. The method of claim 58, comprising:   Authenticating the second user includes receiving a user ID and a second password related to the second user via the second channel and authenticating the second user based on the user ID and the second password. 59. The method of claim 58, comprising. In the method wherein the resource requires the second authentication parameter and at least one additional authentication parameter,
Authenticate at least one additional user;
Receiving the token value and at least one additional authentication parameter from at least one additional device via at least one additional channel, wherein at least one additional device is connected to at least one additional user; and 59. The method of claim 58, comprising using to associate the request received from the first device with an indication of the approval received from at least one additional device.   63. The method of claim 62, comprising associating the request received from the first device with the approval indication received from the second device and at least one of the additional devices using the token value. .   59. Generating a credential, the certificate comprising indicating whether the resource may be provided to the first device without an indication of the approval from the second user. The method described.   The credential of claim 64, wherein the credential comprises a cookie, a permanent credential, a time sensitive credential, a credential that expires after a predetermined number of user sessions, or any combination thereof. book. In the method in which the first user attempts to leave a first session and start a new session,
Authenticating the first user;
59. Receiving a request for the resource from the first device, wherein the first device is connected to the first user; and processing information associated with the credential. the method of.   The information related to the credential comprises providing the resource if the resource indicates that the resource is provided to the first device without the approval of the second user. Item 67. The method according to Item 66. A method for determining the first user's access to a resource,
Authenticate the second user;
Receiving a token value, wherein the token value is associated with a user session, wherein the first user accesses a resource based on an indication of approval from the second user;
Transmitting information about the user session to the device; and receiving instructions from the device regarding access of the first user to the resource.   69. The method of claim 68, wherein authenticating a second user includes receiving authentication parameters from a device, wherein the authentication parameters are related to the second user.   69. The method of claim 68, wherein receiving an instruction from the second user comprises receiving an instruction from the second user and terminating the access of the first user to the resource.   69. The method of claim 68, wherein receiving an instruction from the second user includes receiving an instruction from the second user to restrict the access of the first user to the resource.   72. The method of claim 71, wherein the second user may limit the access of the first user according to a deadline or a predetermined number of user sessions.

Images