US-12619971-B2 - Cloud-based application security

US12619971B2US 12619971 B2US12619971 B2US 12619971B2US-12619971-B2

Abstract

Systems, methods, and computer program products for providing cloud-based application security are disclosed. For example, a server part of a cloud-based application may determine a plurality of security challenges for authorizing a request based on a plurality of security settings of a user account and one or more attributes of the request, issue a first-level authorization challenge and a second-level authorization challenge based on the determining, identify a plurality of available resources from the user account for the request, and responsive to successful completion of the first-level authorization challenge and the second-level authorization challenge, automatically apply two or more of the available resources from the user account to fulfill the request based on the one or more attributes of the request and a physical location associated with the request.

Inventors

Sebastien Taveau
Nadav Naaman

Assignees

PAYPAL, INC.

Dates

Publication Date: 20260505
Application Date: 20220923

Claims (20)

1 . A system, comprising: a non-transitory memory, and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising: receiving, from a user device associated with a user, a request for processing a transaction through a user account; providing a first-level authentication challenge to the user device, wherein the first-level authentication challenge is performed locally on the user device; authenticating the user for accessing the user account at a first access level based on a first set of inputs received from the user device in response to the first-level authentication challenge; determining a set of criteria for processing the transaction without requiring a second-level authentication challenge based on a balance of the user account and a risk profile associated with a user of the user account, wherein the risk profile is generated for the user account based on historic interactions between the user and the system; determining whether the second-level authentication challenge is required for authenticating the user for the transaction based on the set of criteria and attributes associated with the request, wherein the second-level authentication challenge is performed via communications between the user device and a service provider server via a network; and in response to determining that the second-level authentication challenge is not required, enabling the user device to process the transaction according to the first access level.
2 . The system of claim 1 , wherein the first set of inputs is associated with a first modality, and wherein the second-level authentication challenge requires a second set of inputs associated with a second modality different from the first modality.
3 . The system of claim 2 , wherein the first set of inputs comprises a passcode, and wherein the second set of inputs required by the second-level authentication challenge comprises biometric information of the user.
4 . The system of claim 3 , wherein the second set of inputs comprises a fingerprint scan of the user.
5 . The system of claim 1 , wherein the set of criteria comprises a threshold, and wherein the operations further comprise: determining whether an attribute of the transaction exceeds the threshold; and determining that the second-level authentication challenge is not required based on the attribute not exceeding the threshold.
6 . The system of claim 5 , wherein the transaction is a payment transaction, and wherein the attribute comprises a payment amount associated with the payment transaction.
7 . The system of claim 1 , wherein the determining whether the second-level authentication challenge is required for authenticating the user is further based on a user preference associated with the user account.
8 . A method comprising: receiving, from a user device associated with a user, a request for processing a transaction through a user account; authenticating, by a computer system and via a first-level authentication challenge, the user for accessing the user account according to a first access level, wherein the first-level authentication challenge is performed locally on the user device; determining, by the computer system, a set of criteria for processing the transaction without requiring a second-level authentication challenge based on historic interactions between the user and the computer system; determining, by the computer system, whether the second-level authentication challenge is required for processing the transaction for the user based on the set of criteria and a first attribute associated with the transaction, wherein the second-level authentication challenge is performed via communications between the user device and a service provider server via a network; and in response to determining that the second-level authentication challenge is not required for processing the transaction, processing the transaction for the user using a first set of resources associated with the user account.
9 . The method of claim 8 , wherein the request is a first request for processing a first transaction for the user, and wherein the method further comprises: subsequent to processing the first transaction, receiving, from the user device, a second request for processing a second transaction through the user account; determining that the second-level authentication challenge is required for processing the second transaction; providing the second-level authentication challenge to the user device; and authenticating the user for accessing the user account according to a second access level based on the communications between the user device and the service provider server and a response from the second-level authentication challenge by the user device.
10 . The method of claim 9 , wherein the authenticating the user for accessing the user account according to the second access level enables the user to access a second set of resources associated with the user account, and wherein the method further comprises: processing the second transaction for the user using the second set of resources associated with the user account.
11 . The method of claim 8 , wherein the transaction comprises a data access transaction for accessing first content, wherein the set of criteria comprises a content sensitivity threshold, and wherein the method further comprises: determining a sensitivity level corresponding to the first content; and determining that the second-level authentication challenge is not required for processing the data access transaction based on the sensitivity level corresponding to the first content not exceeding the content sensitivity threshold.
12 . The method of claim 8 , wherein the transaction comprises a payment transaction, wherein the set of criteria comprises a threshold, and wherein the method further comprises: determining whether an attribute of the payment transaction exceeds the threshold; and determining that the second-level authentication challenge is not required based on the attribute not exceeding the threshold.
13 . The method of claim 12 , wherein the attribute comprises a payment amount associated with the payment transaction.
14 . The method of claim 8 , wherein the first-level authentication challenge requires a first set of inputs associated with a first modality, and wherein the second-level authentication challenge requires a second set of inputs associated with a second modality different from the first modality.
15 . A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations comprising: receiving, from a user device of a user, a request associated with a user account; authenticating, using a first-level authentication challenge, the user for the request according to a first access level, wherein the first-level authentication challenge is performed locally on the user device; determining a set of criteria for processing the request without requiring a second-level authentication challenge based on a risk profile associated with the user, wherein the risk profile is generated for the user based on historic transactions conducted by the user through the user account; determining whether the user is required to be authenticated using the second-level authentication challenge based on one or more attributes associated with the request and the set of criteria, wherein the second-level authentication challenge is performed via communications between the user device and a service provider server via a network; and in response to determining that the user is not required to be authenticated using the second-level authentication challenge, providing the user device access to a first set of resources associated with the user account for the request according to the first access level.
16 . The non-transitory machine-readable medium of claim 15 , wherein the request is for accessing content from the user account, wherein the set of criteria comprises a content sensitivity threshold, and wherein the operations further comprise: determining a sensitivity level corresponding to the content; and determining that the user is not required to be authenticated using the second-level authentication challenge for processing the request based on the sensitivity level corresponding to the content not exceeding the content sensitivity threshold.
17 . The non-transitory machine-readable medium of claim 15 , wherein the request is for processing a payment transaction through the user account, wherein the set of criteria is associated with a threshold, and wherein the operations further comprise: determining whether an attribute of the payment transaction exceeds the threshold; and determining that the user is not required to be authenticated using the second-level authentication challenge for processing the payment transaction based on the attribute not exceeding the threshold.
18 . The non-transitory machine-readable medium of claim 17 , wherein the attribute comprises a payment amount associated with the payment transaction.
19 . The non-transitory machine-readable medium of claim 15 , wherein the first-level of authentication challenge requires a first set of inputs associated with a first modality, and wherein the second-level of authentication challenge requires a second set of inputs associated with a second modality different from the first modality.
20 . The non-transitory machine-readable medium of claim 15 , wherein the determining whether the user is required to be authenticated using the second-level authentication challenge for processing the request is further based on a user preference associated with the user account.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. patent application Ser. No. 16/438,280, filed Jun. 11, 2019, which is a continuation of U.S. patent application Ser. No. 15/468,008, filed Mar. 23, 2017, now U.S. Pat. No. 10,318,948, issued Jun. 11, 2019, which is a continuation of U.S. patent application Ser. No. 13/165,180, filed Jun. 21, 2011, and claims priority to U.S. Provisional Patent Application Ser. No. 61/359,667, filed Jun. 29, 2010, both of which are incorporated by reference in their entirety. BACKGROUND Field of the Invention The present invention generally relates to making payments using mobile devices, and more particularly, to using the mobile device to intelligently make payments. Related Art Electronic payments are becoming a preferred method of payment because they offer advantages to the user not present with traditional physical payments. With a physical payment, the user is required to carry the funding instrument and present the funding instrument when ready to make a payment. Examples of physical funding instruments include cash, checks, credit cards, debit cards, coupons, gift certificates, gift cards, and the like. These can take up space in a user pocket, purse, or wallet. To reduce space, the consumer may not carry all funding instruments all the time, resulting in the possibility that a desired funding instrument is not available when the consumer is ready to use it at a point of sale (POS). Such physical funding instruments may also be lost or stolen. Thus, physical “wallets” can be cumbersome, inconvenient, and prone to loss. To remedy this, mobile devices have been and are being used to make payments through payment providers, such as PayPal, Inc. of San Jose, CA Such payment providers typically allow a consumer to make a payment through the user's mobile device, such as through the use of barcodes, communication between the payment provider and the merchant, and other methods. After authentication and/or authorization, the payment is made through a user account with the payment provider, where the account is funded through a funding source, such as the user's bank or credit card. The funding source is typically a single default source selected by the user. While this may allow the consumer to forego carrying credit cards, bank cards, and cash, the user must still decide whether to use the payment provider service, another payment service on the mobile device, or a physical funding instrument. This can be disadvantageous, which also applies to physical wallets, because the user must decide which of the many possible funding instruments to use for a particular purchase. This may result in the user choosing a payment instrument that is not the “best” choice for the transaction. Therefore, a need exits for a payment solution that overcomes the disadvantages described above with conventional payment methods. SUMMARY According to one embodiment, a consumer has an account with a payment provider, such as PayPal, Inc. The account includes at least one funding source, and preferably several. When the user is ready to make a purchase or payment, such as at a point of sale, the payment provider selects what funding source (e.g., Visa, AMEX, credit cards associated with different rewards programs, PayPal, bank account, coupons, gift cards, etc.) to use based on the transaction information, including the amount, type of purchase, merchant, location, etc. The selection can be based on user selected preferences, payment history of user, goals, preferred or incentivized payment sources of the merchant, or any combination of logic. For example, there may be discounts or other rewards at a certain store if a specific card is used, the user may want to primarily use a card to get sufficient reward points for a goal, the user may want to limit certain cards to a maximum monthly or transaction amount, an AMEX Hilton card may be selected for use at a Hilton hotel, etc. This greatly reduces the time and effort for the user to decide which card or other funding instrument to use. This also helps the user make use of coupons, etc., as part of the funding. The payment provider may also provide payment directly from a funding source to the merchant so that the recipient need not have an account with the payment provider. This may also apply when the user does not have a payment provider account. According to another embodiment, different authentication or security levels are applied to different uses of the user device. For example, payments may require one type of authentication, while non-payments (such as information transfers or displays) may require another type of authentication. Within payments or non-payments, there may be additional different security levels. For example, higher security may be required for higher payment amounts and use or display of more sensitive information, such as social security number, credit card number, and the like. These and oth