Patent Application
20160232516
Mobile devices, such as smartphones, and wearable computing devices, such as computerized watches, may be promising platforms for payments, replacing the more traditional practices of cash, checks and credit cards. However, one of the challenges with the design of a mobile payment system is the balance between security and a hassle free user experience. Each of these two goals is achievable on its own at the expense of the other. For example, requiring a user to enter a password each time they pay electronically may result in a poor user experience. On the other hand, authorizing such payments without requiring authentication for each payment may create a potential for abuse by unauthorized persons and financial loss.
In one example, a device includes one or more processors, one or more sensors to generate sensor data, one or more communication units and one or more modules. The one or more modules are operable by the one or more processors to, prior to initiating a payment transaction, analyze the sensor data to determine a risk level for the payment transaction, and initiate the payment transaction with a payment system. The one or more modules are further operable by the one or more processors to determine a risk level threshold for the payment transaction, and selectively send, based on the risk level determined prior to the payment transaction and the risk level threshold and using the one or more communication units, authorization for the payment transaction.
The details of one or more examples of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
Techniques according to the disclosure may enable a computing device, such as a mobile computing device, wearable computing device, etc., to predictively authorize mobile payments such that a user may be able to make a mobile payment without requiting a user to input a response to an authentication challenge. In order to determine whether to predictively authorize a mobile payment, a computing device may monitor inputs from one or more sensors of the device, compare the sensor inputs to preconfigured sensor input patterns associated with an authorized user of the device to determine if the user attempting to make the mobile payment is an authorized user of the computing device. In addition, the computing device may perform a risk assessment (e.g., based on the likelihood that an authorized user is the one attempting to make the mobile payment and the relative cost of error if the mobile payment is incorrectly authorized) to determine whether or not the mobile payment should be authorized. Responsive to determining that the risk associated with authorizing the mobile payment satisfies a threshold amount of risk, the computing device may authorize the mobile payment transaction. In this way, techniques of this disclosure may enable a computing device to authorize a mobile payment without requiring a user to complete an explicit security challenge, thereby reducing the number of steps required to complete the mobile payment, which may result in a better user experience without significantly increasing the risk of abuse by unauthorized persons and financial loss.
Throughout the disclosure, examples are described where a computing device and/or a computing system may analyze information (e.g., locations, speeds, etc.) associated with a computing device only if the computing device receives permission from the user to analyze the information. For example, in situations discussed below in which the computing device may collect or may make use of information associated with the user, the user may be provided with an opportunity to provide input to control whether programs or features of the computing device can collect and make use of user information (e.g., information about a user's current location, current speed, motion, etc.), or to dictate whether and/or how to the computing device may receive content that may be relevant to the user. In addition, certain data may be treated in one or more ways before it is stored or used by the computing device and/or computing system, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can he determined about the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about the user and used by the computing device.
Payment system 12 may be any payment device usable for processing mobile payment transactions. In some examples, payment system 12 may be a stand-alone device while, in other examples, payment system 12 may be a hardware accessory coupled to a different device or a software system installed on a device. In some instances, payment system 12 is a remote payment system associated with an online store. In general, payment system 12 may receive payment information from and/or transmit financial transaction information to another device. Typically, in mobile payment systems, the other device is a mobile device, such as mobile computing device 10, but is not so limited.
Mobile computing device 10 may communicate with payment system 12 when performing mobile payments. For example, mobile computing device 10 may receive transaction information from payment system, such as information about the payee (identity of the payee, location of the payment system, etc.), goods and/or services being purchased, price of the goods and/or services being purchased, etc. Mobile computing device 10 may also transmit information to payment system 12, including payment authorization for the pending transaction. When communicating with payment system 12, mobile computing device 10 may use wired or wireless communication mechanisms, such as Bluetooth, near-field communication (NFC), Wi-Fi, infrared, universal serial bus, Ethernet, cellular networks, etc.
A user associated with mobile computing device 10 can interact with mobile computing device 10 by providing various user inputs into mobile computing device 10, e.g., using at least one UI device 14. In some examples, the at least one UI device 14 is configured to receive tactile, audio, or visual input. In addition to receiving input from a user, UI device 14 can be configured to output content such as a graphical user interface (GUI) for display, e.g., at a display device associated with mobile computing device 10. In some examples, UI device 14 can include a display and/or a presence-sensitive input device. In some examples, the display and the presence-sensitive input device may be integrated into a presence-sensitive display, which displays the GUI and receives input from the user using capacitive, inductive, and/or optical detection at or near the presence sensitive display. In other examples, the display device can be physically separate from a presence-sensitive device associated with mobile computing device 10.
Analysis module 20 may receive information from one or more sensors 16 and store at least an indication of the information received from sensors 16 in user data 26. Sensors 16 may include motion sensors e.g., accelerometer, gyroscope, compass, etc.), audio and/or visual sensors (e.g., microphones, still and/or video cameras, etc.), or other types of sensors (e.g., pressure sensors, light sensors, proximity sensors, ultrasonic sensors, global positioning system sensors, etc.). User data store 26 may represent any suitable storage medium for storing data. For example, user data store 26 may store sensor information data received by analysis module 42 as well as exemplary sensor data patterns for users authorized to make mobile payments using mobile computing device 10.
Analysis module 20 may periodically or continually receive and store the sensor information. At least periodically, analysis module 20 analyzes the sensor information to determine a likelihood that the sensors information corresponds to an authorized user of mobile computing device 10. For example, analysis module 20 may apply an analysis of the sensor data, both the sensor data currently being received as well as the previously received sensor data (e.g., stored within a memory of mobile computing device 10 and/or within user data 26), and construct a risk metric. The risk metric may be a single risk metric for any mobile payment or may include multiple different risk metrics, each of which may be associated with a different category of mobile payment transaction. The analysis may be a machine learning algorithm, a rule base, a decision tree, mathematical optimization, or any other algorithm suitable for determining a likelihood that the sensor data corresponds an authenticated user of mobile computing device 10. In various instances, analysis module 20 may periodically store a determined risk metric in user data 26 for use in a future mobile payment transaction.
Payment module 22 may interface with payment system 12. When mobile computing device 10 is utilized to initiate a mobile payment, payment module 22 may receive transaction information, such as the amount of the transaction, a purpose of the transaction (e.g., payment, refund, etc.), an identity of the merchant, etc., and may request authorization from resolution module 24.
Resolution module 24 may determine whether or not the transaction is authorized based on the risk metric as well as the transaction information. For example, resolution module 24 may determine that the transaction is a purchase and that the transaction amount is greater than $1,000. As such, resolution module 24 may determine that a cost of incorrectly authorizing the transaction is relatively high. As a result, resolution module 24 may require the risk metric to satisfy a stricter threshold (i.e., require a higher likelihood that mobile computing device 10 is being used by an authorized user in order to authorize the transaction). As another example, resolution module 24 may determine that the transaction is a purchase and that the transaction amount is less than $10. Based on these determinations, resolution module 24 may determine that the cost of incorrectly authorizing the transaction is relatively low and require the risk metric satisfy a more lenient threshold (i.e., require a lower likelihood that mobile computing device 10 is being used by an authorized user in order to authorize the transaction). If resolution module 24 also determined that the current location of mobile computing device 10 is far away from a home of the user (e.g., 10 miles away) and the purchase is for a bus ticket, resolution module 24 may determine that the costs of incorrectly determining that the transaction is not authorized is relatively high, resolution module 24 may further reduce the threshold.
In some examples, resolution module 24 may also authorize the transaction based on prior transactions and other information stored in user data 26, as well as current location information, current time and date information, etc. For example, if a user typically visits a particular coffee shop on Monday mornings, resolution module 24 may determine that the current day is a Monday, the time of day is morning, and the location of mobile computing device 10 corresponds to the coffee shop. Moreover, resolution module 24 may determine that the amount of the transaction may be within a threshold of the average transaction for the user at this coffee shop. Based on these determinations, resolution module 24 may require a relatively low threshold for the risk metric to satisfy before authorizing the transaction. That is, resolution module 24 may alter the risk threshold based on sensor information, past user behavior, and transaction information.
In situations discussed throughout in which the computing device may collect or may make use of information associated with the user, the user may be provided with an opportunity to provide input to control whether programs or features of the computing device can collect and make use of user information (e.g., information about a user's current location, current speed, motion, purchase history, location history, etc.), or to dictate whether and/or how to the computing device may receive content that may be relevant to the user. In addition, certain data may be treated in one or more ways before it is stored or used by the computing device and/or computing system, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined about the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about the user and used by the computing device.
Resolution module 24 provides an indication of whether the transaction was authorized to payment module 22. If the transaction was authorized, payment module 22 transmits the payment information to payment system 12. If the transaction was not authorized, payment module 22 may cause user interface device 14 to output an indication as to why the transaction was not approved and may include a request for a user of mobile computing device 10 to perform an authentication challenge (e.g., to input security information, such as a password, a personal identification number (PIN), a pattern or biometric data (e.g., fingerprint, voice, image, or the like)). If the user successfully performs the authentication challenge, payment module 22 may transmit the payment information to payment system 12 and complete the transaction. In some examples, payment module 22 may store an indication that the transaction was authorized after the user completed the security challenge in user data 26 such that analysis module 20 and resolution module 24 may, for future transactions, improve the accuracy and reliability of the results of the risk metric and authorization. If the user does not successfully perform the authentication challenge, payment module 22 will reject the transaction and may refrain from sending payment information to payment system 12.
Analysis module 20 and resolution module 24 may also be user configurable. That is, a user of mobile computing device 10 may configure the risk level the user is willing to accept. For example, if the user configures mobile device 10 to be more willing to accept the risk of fraudulent transactions, then analysis module 20 alter the risk metric calculations to reflect a lower risk of erroneous authentication/rejection of a transaction. Similarly, resolution module 24 may make the risk threshold more lenient such that more transactions may be authorized.
In some examples, a merchant may be able to override the configured level of acceptable risk. For example, merchants that frequently experience fraudulent transactions may cause payment system 12 to send an indication of a higher risk threshold such that resolution module 24 may require a more stringent risk threshold before authorizing the transaction. Similarly, merchants that experience infrequent fraudulent transactions otherwise agrees to accept an increased chance of fraudulent activity, may cause payment system 12 to send an indication of a lower risk threshold such that resolution module 24 may require a more lenient risk threshold before authorizing the transaction.
Mobile computing device 10 may also be configured to detect theft and automatically stop authorizing all or a specified subset of transactions. For example, analysis module 20 may determine, based on accelerometer data from sensors 16, that mobile computing device 10 was grabbed and automatically significantly increase the risk metric such that resolution module 24 stops authorizing mobile payments. In some examples, analysis module 20 may send resolution module 24 an indication that mobile computing device 10 was likely stolen. Using this information, resolution module 24 may selectively authorize transactions, such as bus fare back to a home location of mobile computing device 10, while not authorizing other transactions, such as an online music purchase.
In this way, mobile computing device 10 may be configured to predictively authorize the mobile payment. That is, mobile computing device 10 may determine a risk metric prior to a user initiating a mobile payment transaction and use the predefined risk metric as well as other sensor information and past user behavior to authorize the mobile payment without requiring the user to complete a security challenge at the time of the transaction.
Secondary device 32 may be any computerized device capable of exchanging transaction information with mobile computing device 30 and payment system 34. For example, secondary device 32 may be a wearable computing device, such as, a computerized watch, computerized glasses, a computerized glove, etc. Computerized devices (e.g., a computerized watch, computerized glasses, a computerized glove, etc.) may refer to any electrical computing device configured to store and process data. Electrical computing devices may include, for example, digital computers, analog computers, mobile computers, optical computers, quantum computers, or the like. In some examples, computerized devices may include, for example, at least one processing element (e.g., CPU) and memory (e.g., non-volatile memory, volatile memory, etc.). In some examples, secondary device 32 may be a mobile computing device. As shown in
Telemetry module 40 of mobile computing device 30 and telemetry module 54 of secondary device 32 may be used to communicate with external devices via one or more networks, such as one or more wireless networks. Examples of such wireless networks may include Bluetooth, 3G, LTE, and Wi-Fi wireless networks. In some examples, secondary device 32 utilizes telemetry module 54 to wirelessly communicate with mobile computing device 30.
Mobile computing device 30 may monitor information generated by sensors 38. For example, analysis module 42 may monitor sensor information (e.g., motion data (e.g., accelerometer, gyroscope, and compass data indicative of motion of mobile computing device 30), audio, visual, global positioning system, etc.) and store the sensor information in user data 46. In some examples, analysis module 42 may also analyze application usage information, such as the duration, frequency, location, time, etc., of various applications installed at or otherwise executable by mobile computing device 30. At least periodically, analysis module 42 analyzes the sensor information to determine a likelihood that the sensor information corresponds to an authorized user of mobile computing device 10. For example, analysis module 42 may apply an analysis of the sensor data, both the sensor data currently being received as well as the previously received sensor data (e.g., stored within a memory of mobile computing device 10 and/or within user data 26), and construct a risk metric. In some examples, secondary device 32 may include sensors, user data, an analysis module, and/or a resolution module similar to mobile computing device 30 and the analysis module of secondary device 32 may monitor information (e.g., sensor information generated by sensors of secondary device 32, application usage information, user data stored in secondary device 32, or the like) to determine a likelihood that the information corresponds to an authorized user of secondary device 32 and/or mobile computing device 30.
The risk metric may be a single risk metric for any mobile payment or may include multiple different risk metrics, each of which may be associated with a different category of mobile payment transaction. The analysis may be a machine learning algorithm, a rule base, a decision tree, mathematical optimization, or any other algorithm suitable for determining a likelihood that the sensor data corresponds an authenticated user of mobile computing device 10. In various instances, analysis module 20 may periodically store a determined risk metric in user data 26 for use in a future mobile payment transaction. In some examples, an analysis module of secondary device 32 may periodically store a determined risk metric in a user data of secondary device 32 for use in a future mobile payment transaction.
Payment module 52 may interface with payment system 34. For example, in response to telemetry module 54 receiving a payment request from payment system 34, payment module 52 may determine payment information stored in user data of secondary device 32 for telemetry module 54 to send to payment system 34. When secondary device 32 is utilized to initiate a mobile payment, payment module 52 may receive transaction information, such as the amount of the transaction, a purpose of the transaction (e.g., payment, refund, etc.), an identity of the merchant, etc., and may request authorization from resolution module 44 of mobile computing device 30.
In some examples, secondary device 32 may include an analysis module and/or a resolution module that may be used to permit secondary device 32 to determine whether to send payment information without an authentication challenge (e.g., using mobile computing device 30, using secondary device 32, etc.) or to require satisfaction of an authentication challenge before sending payment information. Resolution module 44 and/or a resolution module of secondary device 32 may determine whether or not the transaction is authorized based on a combination of one or more of the risk metric determined by analysis module 42 and/or an analysis module of secondary device 32, the transaction information, and prior user behavior. Resolution module 44 and/or a resolution module of secondary device 32 may determine that the transaction is authorized, rejected, or requires reauthorization. In some instances, a user may select a risk level. For example, resolution module 44 and/or a resolution module of secondary device 32 may compare a determined risk metric and a user selected risk level (e.g., stored in user data 46, stored in a user data of secondary device 32, stored in a cloud computing system, etc.) in order to determine that a transaction is authorized, rejected, or requires reauthorization. As an example, a user that desires to minimize the potential for abuse by unauthorized persons may select a low risk level and the resolution module 44 and/or a resolution module of secondary device 32 may authorize only transactions where the determined risk metric is below the selected low risk level.
If reauthorization is required, resolution module 44 and/or a resolution module of secondary device 32 can further determine if a higher level of reauthorization (i.e., greater security measure required), which may detract from the user experience, or a lower level of reauthorization (i.e., lower security measure required), which may result in a smoother user experience. In order to satisfy the lower level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use less secure data, such as GPS location information, network neighborhood information determined using Wi-Fi, etc. In order to satisfy the higher level reauthorization requirement, resolution module 44 and/or a resolution module of secondary device 32 may use more reliable data for particularly identifying the user of mobile computing device 30 and secondary device 32, such as fingerprint data, audio data for voice recognition, passwords, pin patterns, visual data for facial recognition, motion data (e.g., when requiring the user to perform a particular gesture using either mobile computing device 30 or secondary device 32), etc. While the various types of data are described as being used for lower level or higher level reauthorization requirements, any of the various types of data may be used for either or both levels of reauthorization requirement and a user may configure which types of data may be used for each level of reauthorization requirement.
In some examples, a security challenge required to reauthorize the user may be performed using either mobile computing device 30 or secondary device 32. For example, if resolution module 44 requires the user to enter a password in order to reauthorize the user, the user may be able to enter the password by providing input to secondary device 32, which transmits the input to mobile computing device 30. As another example, the user may place his/her finger on a fingerprint sensor of secondary device 32 and secondary device 32 may generate the fingerprint information and provide it to resolution module 44.
While described as secondary device 32 requiring mobile computing device 30 to complete a transaction, in some examples, secondary device 32 may authorize a transaction without communicating with mobile computing device 30. For example, after completing a transaction, mobile computing device 30 may provide authorization to secondary device 32 to authorize certain transactions. The pre-authorized transactions may include transactions performed within a certain amount of time from the last transaction authorized by mobile computing device 30. In examples where secondary device 32 is a wearable computing device, the pre-authorized transactions may also include transactions performed while secondary device 32 determines that the user is continuing to wear secondary device 32 such that, if user removes secondary device 32, secondary device 32 must receive authorization from mobile computing device 30 prior to authorizing any other transactions. Additionally or alternatively, the pre-authorized transactions may include transactions performed while secondary device 32 determines that mobile computing device 30 and secondary device 32 are proximate, for example, such that communications messages sent via one or more short range communication protocols (e.g., Bluetooth, NFC, Wi-Fi, or the like) are received by the telemetry module 54. In some examples, the pre-authorized transactions may include transactions performed while secondary device 32 determines that mobile computing device 30 is in a trusted state (e.g., in response to mobile computing device 30 receiving an input satisfying an authentication challenge, in response to a reauthorization of mobile computing device 30, or the like). In some instances, telemetry module 54 may, in response to an analysis module and/or a resolution module of secondary device 32 determining that mobile computing device 30 and secondary device 32 are proximate, determining mobile computing device 30 is in a trusted state, and determining that secondary device 32 is in a worn state, send payment information to payment system 34. In some instances, secondary device 32 may initiate an authentication challenge and, in response to determining that an input satisfies the authentication challenge, secondary device 32 may authorize a transaction (e.g., sending payment information for the payment request, instructing mobile computing device 30 to send payment information, etc.) without communicating with mobile computing device 30.
In some examples, secondary device 32 may be a computing device (e.g., wearable computing device, mobile computing device, etc.) that may be primarily associated with someone other than an authorized user of mobile computing device 30. For example, secondary device 32 may be a primary device for another person, such as a spouse, child, sibling, other relative, friend, or other person. In such examples, secondary device 32 may include additional elements similar to those included in mobile computing device 30, such as sensors, analysis and resolution modules, and a data store for user data.
The authorized user of mobile computing device 30 may provide payment information (e.g., credit card information, banking account numbers, payment system authentication credentials, etc.) to secondary device 32. That is, the person for whom secondary device 32 is a primary device may share payment information with the authorized user of mobile computing device 30. Prior to authorizing a transaction, such as a mobile payment, secondary device 32 may analyze sensor information generated by sensors of secondary device 32 to determine whether a current user of secondary device 32 is the authorized user of mobile computing device 30, the primary user of secondary device 32, or another user. Further, in some examples, the person that entered the payment information may be different from the authorized user of mobile computing device 30. Secondary device 32 may determine if the current user of secondary device 32 is the person that provided the payment information to secondary device 32. In some examples, secondary device 32 may also analyze the sensor information to determine if the current user of secondary device 32 is a child or an adult.
An analysis module of secondary device 32 may use the information determined about the current user of secondary device 32 to determine the risk metric. For example, if the current user of secondary device 32 is a child, the analysis module may determine that a cost associated with a false positive is greater than if the current user were an adult and may determine that the risk metric should be higher. As another example, if the current user of secondary device 32 is the same user that provided the payment information to secondary device 32, the analysis module may determine that the risk metric should be lower. The analysis module of secondary device 32 may use sensor data to determine a current user. For example, secondary device 32 may include one or more sensors touch-sensitive screen, presence-sensitive display, touch-sensitive screen, mouse, keyboard, voice responsive system, video camera, microphone, or the like) that receive a user input (e.g., a password, a personal identification number (PIN), a pattern, biometric data, or the like) and the analysis module of secondary device 32 may select a current user (e.g., child, spouse, or the like) in response to the user input. The analysis module of secondary device 32 may use telemetry module 54 to determine a current user. For example, secondary device 32 may send a communication message using telemetry module 54 to a remote device (e.g., server, cloud computing system, mobile device, computing device, or the like) indicating information (e.g., a received user input, GPS location information, sensor data, or the like) and telemetry module 54 may receive an indication of the current user from the remote device.
A resolution module of secondary device 32 may also utilize the information determined about the current user of secondary device 32 to determine whether a transaction should be authorized, rejected, or if reauthorization is required. For example, if the current user of secondary device 32 is a spouse of the authorized user of mobile computing device 30, the resolution module may apply a more lenient threshold to the risk metric, thereby authorizing additional transactions that may not be authorized if the current user of secondary device 32 were a child. In addition, the resolution module may implement a time window in which all similar transactions to the authorized transactions are automatically authorized without requiring reauthorization. In instances where the current user is the authorized user of mobile computing device 30, a spouse, or other adult primary user of secondary device 32, the resolution module may implement a longer time window than if the current user is a child or an unknown user of secondary device 32.
As shown in the example of
Communication channels 96 may interconnect each of the components 82, 84, 86, 88, 90, 92 and 94 for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels 96 may include a system bus, a network connection, an inter-process communication data structure, or any other process for communicating data.
One or more processors 82 may implement functionality and/or execute instructions within computing device 80. For example, processors 82 on computing device 80 may receive and execute instructions stored by storage devices 94 that execute the functionality of modules 102-118. These instructions executed by processors 82 may cause computing device 80 to read/write/etc. information, such as one or more data files stored within storage devices 94 during program execution. Processors 82 may execute instructions of modules 102-118 to cause UID 86 to output one or more graphical indications of incoming communications for display at UID 86 as content of a user interface. That is, modules 102-118 may be operable by processors 82 to perform various actions or functions of computing device 80, for instance, causing UID 86 to a present a graphical user interface at UID 86.
One or more communication units 88 of computing device 80 may communicate with external devices via one or more wired and/or wireless networks using one or more wired or wireless networking protocols by transmitting and/or receiving network signals on the one or more networks. Examples of communication unit 88 include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, Bluetooth, Wi-Fi, NFC (including active or passive), other active or passive short range communication circuitry, or any other type of device that can send and/or receive information. Other examples of communication units 88 may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers.
One or more output devices 84 of computing device 80 may generate output. Examples of output are tactile, audio, and video output. Output devices 84 of computing device 80, in one example, includes a presence-sensitive display, sound card, video graphics adapter card, speaker, cathode ray tube (CRT) monitor, liquid crystal display (LCD), or any other type of device for generating output to a human or machine.
One or more input devices 90 of computing device 80 receive input. Examples of input are tactile, audio, and video input. Input devices 90 of computing device 80, in one example, includes a presence-sensitive display, touch-sensitive screen, mouse, keyboard, voice responsive system, video camera, microphone, or any other type of device for detecting input from a human or machine.
In some examples, UID 86 of computing device 80 may include functionality of input devices 90 and/or output devices 84. In the example of
While illustrated as an internal component of computing device 80, UID 86 also represents and external component that shares a data path with computing device 80 for transmitting and/or receiving input and output. For instance, in one example, UID 86 represents a built-in component of computing device 80 located within and physically connected to the external packaging of computing device 80 (e.g., a screen on a mobile phone). In another example, UID 86 represents an external component of computing device 80 located outside and physically separated from the packaging of computing device 80 (e.g., a monitor, a projector, etc. that shares a wired and/or wireless data path with a tablet computer).
Sensors 92 may be configured to detect one or more objects in proximity to computing device 80, measure the movement of computing device 80, and may collect other information associated with computing device 80. Examples of sensors 92 that detect and/or measure movement of computing device 80 may include, but are not limited to, accelerometers and gyroscopes. For instance, sensors 92 may be configured to measure the position, rotation, velocity, and/or acceleration of computing device 80. Sensors 92 may also include a clasp sensor (e.g., in examples where computing device 80 is a wearable computing device having a clasp), a galvanic skin response sensor, and any other type of sensor capable of collecting information related to computing device 80.
One or more storage devices 94 within computing device 80 may store information for processing during operation of computing device 80 (e.g., computing device 80 may store data that modules 102-118 may access during execution at computing device 80, including user data 120). In some examples, storage device 94 is a temporary memory, meaning that a primary purpose of storage device 94 is not long-term storage. Storage devices 94 on computing device 10 may configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.
Storage devices 94, in some examples, also include one or more computer-readable storage media. Storage devices 94 may be configured to store larger amounts of information than volatile memory. Storage devices 94 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage devices 94 may store program instructions and/or information (e.g., data) associated with modules 102-118 and operating system 100.
Operating system 106, in some examples, controls the operation of components of computing device 80. For example, operating system 106, in one example, facilitates the communication of modules 1100-118 with processors 82, one or more output devices 84, user interface device 86 (“UID 86”), one or more communication units 88, one or more input devices 90, and one or more sensors 92. Modules 102-118 may each include program instructions and/or data that are executable by computing device 80 (e.g., by one or more processors 82). As one example, analysis module 104, resolution module 106, and payment module 118 can each include instructions that cause computing device 80 to perform one or more of the operations and actions described in the present disclosure.
UI module 100 may cause UID 86 to output a graphical user interface for display, as a user of computing device 80 views output and/or provides input at UID 86. UI module 100 and UID 86 may receive one or more indications of input from a user as the user interacts with the graphical user interface, at different times and when the user and computing device 80 are at different locations. UI module 100 and UID 86 may interpret inputs detected at UID 86 (e.g., as a user provides one or more gestures at one or more locations of UID 86 at which the graphical user interface is displayed) and may relay information about the inputs detected at UID 86 to one or more associated platforms, operating systems, applications, and/or services executing at computing device 80, to cause computing device 80 to perform functions.
UI module 100 may receive information and instructions from one or more associated platforms, operating systems, applications, and/or services executing at computing device 80 for generating a graphical user interface. In addition, UI module 100 may act as an intermediary between the one or more associated platforms, operating systems, applications, and/or services executing at computing device 80 and various output devices of computing device 80 (e.g., speakers, LED indicators, audio or electrostatic haptic output device, etc.) to produce output (e.g., a graphic, a flash of light, a sound, a haptic response, etc.) with computing device 80.
Computing device 80 may receive, via communication units 88, an incoming message (e.g., from payment system 12 of
In order to determine the current risk level, analysis module 104 may analyze information received from one or more of modules 108-116 as well as information stored by user data 120. For example, voice detection module 108 may analyze audio samples collected by one of input devices 90 (e,g., a microphone) and compare the audio samples to stored voice samples for authorized users of computing device 80 to determine if the current user of computing device 80 is an authorized user (e.g., a user associated with the payment information, a user authorized to use the payment information, etc.). Voice detection module 108 may provide the result of the comparison to analysis module 104 for use in determining the risk level. For example, if the voice comparison indicates that the current user is not an authenticated user, analysis module 104 may increase the current risk level and vice versa.
As another example, motion module 116 may analyze motion data generated by sensors 92, such as accelerometer, gyroscope, and compass data indicative of motion of computing device 80. In some instances, motion module 116 may compare at least a portion of the motion data to stored motion data of an authorized user (e.g., template motion data). For example, motion module 116 may compare accelerometer data collected while the current user of computing device 80 is walking and compare it to stored accelerometer data of an authorized user of computing device 80 to see if the gait of the current user matches or is within a threshold margin of error of the gate of the authorized user. Motion module 116 may provide the result of this comparison to analysis module 104. For example, if the gait of the current user corresponds to an authenticated user, analysis module 104 may decrease the risk level, and vice versa.
Analysis module 104 may also use information from device location module 116 in determining the current risk level. Device location module 116 may receive location information from one of sensors 92 (e.g., a GPS sensor) and determine the location of computing device 80 at the time analysis module 104 is generating the risk level, which may he before initiation of the mobile payment transaction. In some examples, device location module 116 may determine whether the current location of computing device 80 is a location frequented by an authorized user of computing device 80. For example, if computing device 80 is at a location corresponding to a workplace of the recipient, device location module 116 may determine that the location corresponds to a location frequented by an authorized user. Based on this determination, analysis module 104 may decrease the current risk level. As another example, if computing device 80 is at a location corresponding to a bar not frequented by an authorized user, device location module 116 may determine that he location does not correspond to a location frequented by an authorized user. Based on this determination, analysis module 104 may increase the current risk level.
Analysis module may also analyze application usage patterns, such as the duration, frequency, location, time, etc., of various applications installed at or otherwise executable by computing device 80 and store the application usage information at user data 120. When determining the risk level, analysis module 104 may compare the application usage pattern for a recent time window (e.g., within the last 5 minutes, 30 minutes, hour, 2 hours, etc.) to prior application usage patterns for a corresponding time, day, location, etc. If the current application usage pattern is sufficiently similar (i.e., within a threshold amount different) of the corresponding prior application usage pattern, analysis module 104 may reduce the current risk level, and vice versa.
Resolution module 106 may use additional information received from one or more of modules 108-118 and information stored by user data 120 as well as the transaction information to adjust a risk threshold applied to the risk level when determining whether to authorize the transaction. In some examples, resolution module 106 may query user data 120 to retrieve past user behavior data for comparison to the current user behavior in order to determine whether the current mobile payment transaction is a typical mobile payment transaction. The past user behavior data may include location information, merchant information, transaction amount information, date and time information, etc. Resolution module 106 may compare such information to information received from one or more of modules 108-118 as well as the risk level received from analysis module 104 in order to determine whether to authorize, reject, or require reauthorization (including which level of reauthorization is required, such as low or high security level reauthorization).
For example, resolution module 106 may receive a current location of computing device 80 from device location module 116 and compare the current location to previous locations of computing device 80 retrieved from user data 120. If the current location does not correspond to a location computing device 80 previously visited or infrequently visited as determined based on the previous location information, resolution module 106 may increase the risk threshold, thus making it less likely that the transaction will be authorized without at least some level of reauthorization.
As another example, face detection module 112 may receive image data captured by one of input devices 90 (e.g., video data, still image data, etc. captured by a camera and determine if the image data includes one or more individuals. In some examples, face detection module 114 may determine if the image data includes one or more faces. If the image data includes the face of an authorized user, face detection module 114 may determine that the authorized user is currently using computing device 80. If the image data does not include the face of an authorized user, face detection module 114 may determine that an authorized user is not currently using computing device 80. In either instance, face detection module 114 may provide a result of the determination to resolution module 106. Resolution module 106 may decrease the risk threshold in response to face detection module 114 determining that an authenticated user is currently using computing device 80 and vice versa.
Resolution module 106 may also use information received from fingerprint module 114 to determine whether or not to authorize the transaction. Fingerprint module 114 may receive fingerprint information from a sensor 92 (e.g., a fingerprint sensor) and/or user interface device 86 (i.e., in examples where user interface device includes a presence-sensitive input device capable of capturing a fingerprint). Fingerprint module 114 may compare the fingerprint information to stored fingerprint information of an authorized user of computing device 80. If the captured fingerprint information sufficiently matches the stored fingerprint information, fingerprint module 114 provides, to resolution module 106, an indication that the current user of computing device 80 is an authenticated user. Similarly, if the captured fingerprint information does not match, fingerprint module 114 provides, to resolution module 106, an indication that the current user is not an authenticated user. Resolution module 106 adjusts the risk threshold based on the result of the comparison received from fingerprint module 114 (i.e., increasing the risk threshold if the user is not an authenticated user and vice versa).
In examples where resolution module 106 determining that reauthorization is required, resolution module 106 may cause UI module 102 to output instructions for the current user of computing device 80 to complete a security challenge and how to complete the security challenge. Depending on the security challenge, the user may be required to submit to a facial recognition process, provide a fingerprint for fingerprint authentication, enter a passcode, perform an input pattern, provide a voice sample for voice authentication, move computing device 80 in a particular pattern, etc. Regardless of the security challenge required, resolution module 106 may use information from one or more of modules 108-116 to complete the reauthorization and determine whether or not the transaction will be authorized.
In the example of
Secondary device 32 may determine if mobile computing device 30 is proximate to secondary device 32 (172). For example, telemetry module 54 of secondary device 32 may send a message to telemetry module 40 of mobile computing device 30 using one or more short range communication protocols (e.g., Bluetooth protocol, NFC protocol, Wi-fi, or the like) and secondary device 32 may determine that mobile computing device 30 is proximate to secondary device 32 when telemetry module 54 of secondary device 32 receives a reply to the message from mobile computing device 30 (“YES” branch of 172). As an example, in response to telemetry module 54 of secondary device 32 sending the message to telemetry module 40 of mobile computing device 30, telemetry module 40 of mobile computing device 30 may send to telemetry module 54 of secondary device 32 an indication that mobile computing device 30 received the message (e.g., an answer to an inquiry within the message, acknowledgement of a reception of the message, or the like) and secondary device 32 may determine that mobile computing device 30 is proximate to secondary device 32 in response to receiving the indication from mobile computing device 30.
Responsive to determining that mobile computing device 30 is proximate to secondary device 32 (“YES” branch of 172), secondary device 32 may determine whether mobile computing device 30 is in a trusted state (174). For example, telemetry module 54 of secondary device 32 may receive a communication message from telemetry module 40 of mobile computing device 30 indicating that a current user of mobile computing device 30 is an authorized user (“YES” branch of 174). As an example, mobile computing device 30 may send to secondary device 32 an indication that mobile computing device 30 determined an input (e.g., tactile, audio, visual, etc.) detected by mobile computing device 30 corresponds with a preconfigured sensor input pattern associated with an authorized user of mobile computing device 30 and secondary device 32 may determine that mobile computing device 30 is in a trusted state in response to receiving the indication that mobile computing device 30 determined the input detected by mobile computing device 30 corresponds with the preconfigured sensor input pattern.
In examples where secondary device 32 determines that mobile computing device 30 is in a trusted state (“YES” branch of 174), secondary device 32 may determine whether secondary device 32 is in a worn state (176). For example, secondary device 32 may determine that secondary device 32 is in a worn state in response to generating sensor data indicating secondary device 32 is in a physical state corresponding to being worn by a user (“YES” branch of 176). Examples of sensor data indicating secondary device 32 is in a physical state corresponding to being worn by a user may include instances where a clasp sensor of secondary device 32 generates sensor data indicating that secondary device 32 is wrapped around a wrist, where a galvanic skin response sensor of secondary device 32 generates sensor data indicating that secondary device 32 is in direct contract with skin, or the like. As another example, a worn state may include instances where a sensor of secondary device 32 generates sensor data indicating a presence of a user, such as, for example, the sensor data indicating the presence of a temperature or temperature range, a heart rate or heart pulse, gait, or the like.
If secondary device 32 determines that secondary device 32 is in a worn state (“YES” branch of 176), secondary device 32 may send payment information for the payment request to payment system 34 (178). For example, in response to determining that mobile computing device 30 is proximate to secondary device 32, that mobile computing device 30 is in a trusted state, and that secondary device 32 is in a worn state, telemetry module 54 of secondary device 32 may send payment information determined by payment module 52 to payment system 34. In this manner, secondary device 32 may send the payment information to payment system 34 without an authentication challenge, thereby reducing the number of steps required to complete the mobile payment, which may result in a better user experience without significantly increasing the risk of abuse by unauthorized persons and financial loss.
On the other hand, if mobile computing device 30 and secondary device 32 are not proximate (“NO” branch of 172), mobile computing device 30 is not in a trusted state (“NO” branch of 174), or secondary device 32 is not in a worn state (“NO” branch of 176), secondary device 32 may initiate an authentication challenge (180). For example, in response to mobile computing device 30 and secondary device 32 not being proximate, secondary device 32 may prompt a user to input a response (e.g., a PIN, a pattern or biometric data (e.g., fingerprint, voice, image, or the like), or the like to an authentication challenge in order to reduce the risk of abuse by unauthorized persons.
Secondary device 32 may determine whether the response to the authentication challenge is satisfied (182). For example, secondary device 32 may receive an indication of a response to the authentication challenge and secondary device 32 may determine whether a payment for the purchase is authorized (e.g., the authentication challenge is satisfied) based on the response to the authentication challenge. As an example, in response to secondary device 32 initiating the authentication challenge, a sensor of secondary device 32 may detect an indication of a touch input (e.g., PIN input by a user, a biometric data, or the like) and secondary device 32 may determine that the authentication challenge is satisfied and that payment for the purchase is authorized based on a comparison of the touch input to a predefined user selected input (e.g., PIN input by a user during a setup of secondary device 32, PIN stored in a cloud computing system, or the like) indicating a match. In response to the authentication challenge being satisfied (“YES” branch of 182), secondary device 32 may send payment information for the payment request (178).
In some examples, secondary device 32 may use a risk level of the purchase to determine whether to initiate an authentication challenge. For example, in response to mobile computing device 30 being proximate to secondary device 32, mobile computing device 30 being in a trusted state, and secondary device 32 being in a worn state, secondary device 32 may determine a low risk level for the payment transaction. On the other hand, in response to mobile computing device 30 not being proximate to secondary device 32 (e.g., outside of a range of a short range communication protocol), mobile computing device 30 not being in a trusted state, or secondary device 32 not being in a worn state, secondary device 32 may determine a high risk level for the payment transaction.
In some examples, secondary device 32 may modify the risk level in response to sensor data generated by sensors of secondary device 32. For example, secondary device may decrease a risk level when sensor data generated by sensors of secondary device 32 indicate a gait similar to a predefined gait (e.g., a gait corresponding to a user of secondary device 32, a predefined gait stored by secondary device 32, a predefined gait stored in a cloud computing device, or the like). On the other hand, secondary device 32 may increase a risk level when sensor data generated by sensors of secondary device 32 indicate a gait different to the predefined gait. As another example, secondary device 32 may increase a risk level for purchases having a high price and secondary device 32 may decrease a risk level for purchases having a low price.
Secondary device 32 may determine whether to send payment information for a purchase without requiring an authentication challenge in further response to a comparison of the determined risk level with a user selected risk level (e.g., received during a setup of secondary device 32, a predefined risk level, a risk level received from a cloud computing device, or the like). As an example, secondary device 32 may send payment information for a purchase when a risk level for the purchase satisfies (e.g., is less than, greater than, etc.) a predefined user selected input without requiring an authentication challenge and secondary device 32 may require satisfaction of an authentication challenge for sending payment information for a purchase when a risk level for the purchase does not satisfy (e.g., is greater than, less than, etc.) a predefined user selected input.
The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit including hardware may also perform one or more of the techniques of this disclosure.
Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various techniques described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware, firmware, or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware, firmware, or software components, or integrated within common or separate hardware, firmware, or software components.
The techniques described in this disclosure may also be embodied or encoded in an article of manufacture including a computer-readable storage medium encoded with instructions. Instructions embedded or encoded in an article of manufacture including a computer-readable storage medium encoded, may cause one or more programmable processors, or other processors, to implement one or more of the techniques described herein, such as when instructions included or encoded in the computer-readable storage medium are executed by the one or more processors. Computer readable storage media may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a compact disc ROM (CD-ROM), a floppy disk, a cassette, magnetic media, optical media, or other computer readable media. In some examples, an article of manufacture may include one or more computer-readable storage media.
In some examples, a computer-readable storage medium may include anon-transitory medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in RAM or cache).
Various examples of the invention have been described. These and other examples are within the scope of the following claims.
This application claims the benefit of U.S. Provisional Application No. 62/113,218 filed Feb. 6, 2015, the entire content of which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62113218 | Feb 2015 | US |
