U.S. patent application number 16/447822 was filed with the patent office on 2019-10-10 for passive security enforcement.
The applicant listed for this patent is MICROSOFT TECHNOLOGY LICENSING, LLC. Invention is credited to Kim CAMERON, Todd L. CARPENTER, David FOSTER, Quentin S. MILLER, David J. STEEVES.
Application Number | 20190312865 16/447822 |
Document ID | / |
Family ID | 42355255 |
Filed Date | 2019-10-10 |
![](/patent/app/20190312865/US20190312865A1-20191010-D00000.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00001.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00002.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00003.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00004.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00005.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00006.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00007.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00008.png)
![](/patent/app/20190312865/US20190312865A1-20191010-D00009.png)
United States Patent
Application |
20190312865 |
Kind Code |
A1 |
STEEVES; David J. ; et
al. |
October 10, 2019 |
PASSIVE SECURITY ENFORCEMENT
Abstract
Technology is described for enabling passive enforcement of
security at computing systems. A component of a computing system
can passively authenticate or authorize a user based on
observations of the user's interactions with the computing system.
The technology may increase or decrease an authentication or
authorization level based on the observations. The level can
indicate what level of access the user should be granted. When the
user or a component of the computing device initiates a request, an
application or service can determine whether the level is
sufficient to satisfy the request. If the level is insufficient,
the application or service can prompt the user for credentials so
that the user is actively authenticated. The technology may enable
computing systems to "trust" authentication so that two proximate
devices can share authentication levels.
Inventors: |
STEEVES; David J.; (Seattle,
WA) ; CAMERON; Kim; (Bellevue, WA) ;
CARPENTER; Todd L.; (Monroe, WA) ; FOSTER; David;
(Bellevue, WA) ; MILLER; Quentin S.; (Sammamish,
WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MICROSOFT TECHNOLOGY LICENSING, LLC |
Redmond |
WA |
US |
|
|
Family ID: |
42355255 |
Appl. No.: |
16/447822 |
Filed: |
June 20, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15472962 |
Mar 29, 2017 |
10389712 |
|
|
16447822 |
|
|
|
|
14497122 |
Sep 25, 2014 |
9641502 |
|
|
15472962 |
|
|
|
|
14088202 |
Nov 22, 2013 |
8898758 |
|
|
14497122 |
|
|
|
|
12359220 |
Jan 23, 2009 |
8590021 |
|
|
14088202 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 21/316 20130101;
H04L 63/0492 20130101; H04L 67/10 20130101; G06F 21/32 20130101;
H04L 2463/082 20130101; H04W 12/06 20130101; H04L 63/0861 20130101;
H04L 63/08 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04L 29/08 20060101 H04L029/08; G06F 21/32 20060101
G06F021/32; H04W 12/06 20060101 H04W012/06; G06F 21/31 20060101
G06F021/31 |
Claims
1. A method for passive authentication by a computing system, the
method comprising: receiving, by the computing system, a first
attribute; passively authenticating, by the computing system, a
user at a first authentication level based on comparing the first
attribute to one or more first previously stored attributes;
receiving, by the computing system, a second attribute; and
passively updating, by the computing system, the first
authentication level to a second authentication level different
from the first authentication level based on comparing the second
attribute to one or more second previously stored attributes,
wherein the first and second attributes each comprise an event
indicative of the user or a physical characteristic of the user,
and wherein each previously stored attribute comprises a previously
stored event, a previously stored physical characteristic, or one
or more previously determined acceptable values for one or more
users.
2. A system for passive authentication, the system comprising: one
or more computer-readable media having instructions stored thereon;
and one or more hardware processors coupled to the one or more
computer-readable media, and configured to read instructions from
the one or more computer-readable media to cause the system to
perform operations comprising: receiving, by the system, a first
attribute having a first weight; receiving, by the system, a second
attribute having a second weight, wherein the first and second
attributes each comprise an event indicative of the user or a
physical characteristic of the user; computing an overall weighted
confidence level based upon the first attribute having the first
weight and the second attribute having the second weight; comparing
the overall confidence level to a confidence level based upon
previously stored attributes corresponding to the first attribute
and the second attribute, wherein each previously stored attribute
comprises a previously stored event, a previously stored physical
characteristic, or one or more previously determined acceptable
values for one or more users; and passively authenticating, by the
system, a user at an authentication level based on the comparison
of the overall confidence level to the confidence level based upon
the one or more previously stored attributes.
3. A method for passive authentication by a computing system, the
method comprising: receiving, by the computing system, a first
attribute having a first weight; receiving, by the computing
system, a second attribute having a second weight, wherein the
first and second attributes each comprise an event indicative of
the user or a physical characteristic of the user; comparing the
received first and second attributes to respective previously
stored attributes corresponding to the first attribute and the
second attribute, wherein each previously stored attribute
comprises a previously stored event, a previously stored physical
characteristic, or one or more previously determined acceptable
values for one or more users; computing an overall weighted
confidence level based upon one or more of the comparison of the
received first and second attributes to the respective previously
stored attributes, the first weight of the first attribute, and the
second weight of the second attribute; and passively
authenticating, by the computing system, a user at an
authentication level based on a comparison of the overall
confidence level to a threshold confidence level.
4. A computer-readable storage device store computer-executable
instructions that, when executed, perform a method of passively
authenticating a user, the method comprising: receiving, by the
storage device, a first attribute having a first weight; receiving,
by the storage device, a second attribute having a second weight,
wherein the first attribute and second attribute each comprise an
event indicative of the user or a physical characteristic of the
user; computing an overall weighted confidence level based upon the
first attribute having the first weight and the second attribute
having the second weight; comparing the overall confidence level to
a confidence level based upon previously stored attributes
corresponding to the first attribute and the second attribute,
wherein each previously stored attribute comprises a previously
stored event, a previously stored physical characteristic, or one
or more previously determined acceptable values for one or more
users; and passively authenticating, by the storage device, a user
at an authentication level based on the comparison of the overall
confidence level to the confidence level based upon the one or more
previously stored attributes.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. application Ser.
No. 15/472,962, filed Mar. 29, 2017, which is a continuation of
U.S. application Ser. No. 14/497,122, filed Sep. 25, 2014, and
issued as U.S. Pat. No. 9,641,502, which is a continuation of U.S.
application Ser. No. 14/088,202, filed Nov. 22, 2013, and issued as
U.S. Pat. No. 8,898,758, which is a continuation of U.S.
application Ser. No. 12/359,220, filed Jan. 23, 2009, and issued as
U.S. Pat. No. 8,590,021, which are hereby incorporated by reference
in their entirety. In cases in which a document incorporated by
reference herein is inconsistent with contents of this application,
the contents of this application control.
BACKGROUND
[0002] Many computing systems provide various features to enforce
security. Enforcing security includes evaluating and enforcing
authentication and authorization. Computing devices employ
authentication to securely identify users. A computing device
generally employs an authentication component to determine who a
user is and whether the user is really who they claim to be. A
concept related to authentication is authorization. Computing
systems employ authorization to determine the level of access for
the authenticated user. For example, a computing system may
evaluate authorization rules to determine what features or
resources an authenticated user should be provided access to (e.g.,
to access, add, create, delete, modify, etc.) Once a computing
system authenticates a user, the computing system may provide
various features to the user based on that user's authorization.
The computing system can employ an authorization component to
determine the appropriate level of authorization, such as by
enforcing authorization rules.
[0003] Computing systems conventionally enforce security actively.
Active authentication generally includes receiving authentication
information directly from a user who is to be authenticated. As
examples, users may provide login credentials (e.g., user id and/or
password), place a card key or other device proximate to a user, or
take some other active step to identify and/or authenticate
themselves. Thus, active authentication generally involves
verifying a "secret" that is shared between the user and the
computing system or validating a user's response to a challenge.
Active authorization includes enforcing rules based on the
authentication.
[0004] However, authentication can sometimes get in the way of
authorization when some features or transactions provided by a
computing system require a different "level" of authentication than
other features. As an example, when the computing system is a
mobile telephone, a user may require a first level of
authentication to place local phone calls and a second, different
level of authentication to place long distance phone calls or
conduct an electronic commerce transaction. As another example, the
user may need a third level of authentication to browse public
Internet websites but a fourth, different level of authentication
to send or receive electronic mail.
[0005] Although features provided by a computing system can be
divided into different categories, such divisions are ineffective
when, e.g., the user is not yet authenticated, authenticating a
user actively is unnecessary, or a feature requires a different
level of authorization than the level that can be provided to the
authenticated user.
SUMMARY
[0006] Technology is described for enabling passive security
enforcement at computing systems ("the technology"). A component of
a computing system can passively authenticate or authorize a user
based on observations of the user's interactions with the computing
system. The observations can include, e.g., physical observations
of the user's interactions, behavioral observations of the user's
usage of the computing system, etc. The technology may increase or
decrease an authentication level or authorization level based on
the observations. The level can indicate what level of access the
user should be granted. When the user or a component of the
computing device initiates a request, an application or service can
determine whether the level is sufficient to satisfy the request.
If the level is insufficient, the application or service can prompt
the user for credentials so that the user is actively
authenticated. The level may change over time, such as based on
observed actions of the user.
[0007] The technology may enable computing systems to "trust"
authentication so that two proximate devices can share
authentication levels. When the computing device is placed near
another computing device that has also authenticated the user, the
authentication levels for the user at one or both devices may
increase.
[0008] In various embodiments, physical observation can include
proximity of other devices so that, for example, a mobile computing
system may provide a higher authentication level if the user is
carrying another device, such as a car ignition key embedded with
embedded electronics (also know as a "key fob"). When the
previously recognized key fob is no longer proximate to the
computing system, the computing system may decrease the
authentication level it passively provided.
[0009] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used as an aid in determining the scope of
the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] FIG. 1 is a block diagram illustrating components employed
by the technology in various embodiments.
[0011] FIG. 2 is a flow diagram illustrating a routine performed by
a service upon receiving a request from a client to complete a
transaction.
[0012] FIG. 3 is a flow diagram illustrating a routine performed by
a computing system to observe confidence factors.
[0013] FIG. 4 is a flow diagram illustrating a routine performed by
a computing system to compute a confidence level.
[0014] FIG. 5 is a flow diagram illustrating a routine performed by
a computing system to provide a confidence level.
[0015] FIG. 6 is a flow diagram illustrating a routine performed by
a computing system to provide confidence factors.
[0016] FIGS. 7A and 7B are flow diagrams illustrating a routine
performed by a computing system to check selected confidence
factors.
[0017] FIG. 8 is a block diagram illustrating components employed
by the technology in various embodiments.
DETAILED DESCRIPTION
[0018] Technology is described for enabling passive security
enforcement at computing systems, e.g., mobile computing devices
("the technology"). A component of a computing system can passively
authenticate or authorize a user based on observations of the
user's interactions with the computing system. The observations can
include, e.g., physical observations of the user's interactions,
behavioral observations of the user's usage of the computing
system, etc. As examples, physical observations can include, e.g.,
observations of heat or temperature sensors, pressure/touch
sensors, motion sensors/accelerometers, proximity of other devices,
and so forth. Behavioral observations can include, e.g.,
observations of whether the user is telephoning people in a
previously stored contacts list, is located in an area where the
user has been previously observed to be located, and so forth. If
the user's physical and/or behavioral observations are consistent
with prior patterns, the user may be passively authenticated at an
observed authentication "level." If several observations are
consistent with prior patterns, the level may increase. On the
other hand, if only few observations are consistent with prior
patterns or some observations are inconsistent with prior patterns,
the level may decrease. The technology may make observations by
using various hardware and software components to detect changes to
various inputs that are made to the computing system.
[0019] When the user accesses a feature or requests a transaction,
an associated application or service may determine from the
computing system (e.g., by accessing an application program
interface ("API") provided by an operating system executing on the
computing system) what level of authentication the technology has
passively observed. If the authentication level is sufficiently
high (e.g., exceeds a specified threshold level), the application
or service may complete the request. As an example, when the user
places a local telephone call to a telephone number that is not in
the contacts list, the computing system may initiate the call. As
another example, when the user browses a public website, the
computing system may cause the web browser to place the request to
a web server.
[0020] These authorizations may occur because the user, system
administrator, application, or other entity determined that these
features/transactions may be performed at the present
authentication level. As an example, a local phone call may be
"free" but a long distance phone call may cause the user to incur a
fee. As another example, browsing a public website may be "free"
and of acceptable risk, but checking a bank balance or purchasing
an item online may involve unacceptable risk at the present
authentication level.
[0021] If the authentication is not sufficiently high for the
requested feature or transaction, the application or service may
either return an error or require active authentication. To
actively authenticate a user, the operating system may require the
user to provide the user's authentication credentials. As an
example, when the user places a long distance telephone call, the
computing system may not place the telephone call and instead may
prompt the user for the user's login credentials. After verifying
the login credentials actively, the computing system may place the
call. As another example, when the user requests a financial
transaction to a service using the browser, the service may require
a high authentication level. Upon determining that the present
authentication level is lower than a threshold the service
specifies, the computing system may prompt the user for the user's
login credentials. After verifying the login credentials the user
provides, the computing system may inform the service that the
user's authentication level is sufficiently high to complete the
transaction. Alternatively, the service may determine based on the
provided credentials that the requested transaction can be
completed. In various embodiments, the API may indicate the
authentication level to an inquiring service, merely inform the
service that the user's authentication level exceeds a specified
threshold or not, or even transmit credentials to the service. As
an example, upon receiving a request to complete a transaction, the
service may first send a request to the user's computing system
indicating that the service requires a specified authentication
level. If the user's computing system determines that the user's
present authentication system is too low, it may either prompt the
user to enter one or more credentials or inform the service that
the authentication level is too low. In the latter case, the
service may prompt the user to provide credentials so that the
service can authorize the user.
[0022] The computing system may also passively authorize users,
such as by employing techniques similar to those described above
for passive authentication. As an example, after the user has been
passively authenticated, the user may request a transaction that
requires a stronger level of authentication. An authorization
component may have passively determined that the user is or is not
authorized to request the transaction. If the user is not
authorized to request the transaction, the transaction will not be
completed. In various embodiments, the computing device may cancel
the request or provide relevant information so that a service or
application that satisfies the request can determine whether or not
the transaction should be completed.
[0023] Authentication and authorization may be for different time
periods. As an example, the computing system may authenticate a
user for a given "session" (e.g., during a period of time) but may
authorize each transaction separately.
[0024] In various embodiments, the technology may enable computing
systems to "trust" authentication. As an example, the computing
systems may employ near-field communications technology to
communicate authentication information with each other. If the user
has a higher level of authentication on either computing system,
both computing systems may recognize the higher authentication
level. As an example, when a user of a mobile phone has been
passively authenticated but has not been authenticated on a
"surface" computing system and places the mobile phone on the
surface computing system, the surface computing system may
automatically authenticate the user so that, e.g., the user's
photos on the phone can be displayed on the surface computing
system. Alternatively, if the user has already authenticated
actively on one computing system, another proximate computing
system may enable the user to perform activities that it previously
would not have authorized without first prompting the user for
active authentication information.
[0025] The authentication level may change over time. As an
example, if the user begins telephoning users not in the user's
contacts list, the authentication level may decrease. If the
authentication level decreases lower than a specified threshold,
the user may no longer be able to make telephone calls until the
user is prompted for authentication credentials and is (actively)
authenticated.
[0026] In various embodiments, physical observation can include
proximity of other devices. As an example, a mobile computing
system may provide a higher authentication level if the user is
carrying another device, such as a key fob. When the previously
recognized key fob is no longer proximate to the computing system,
the computing system may decrease the authentication level it
passively provided.
[0027] In various embodiments, the technology can employ geographic
position information (e.g., based on radio triangulation, satellite
global positioning system information, etc.) to determine that the
user should be actively authenticated or authorized. For example,
this may occur when the position information indicates that the
user is outside areas that the user normally visits.
[0028] In various embodiments, the technology may not initially
offer passive authentication or authorization because it has not
yet observed and stored attributes of actions. As an example, when
a user first purchases a mobile computing device, the mobile
computing device may only offer active authentication and
authorization. In such a case, the user may need to actively
authenticate before accessing a feature or requesting a
transaction. Over time, as the technology observes and stores usage
patterns (e.g., after one or more instances of a user using the
device), the technology may enable passive authentication and/or
passive authorization.
[0029] In various embodiments, the technology may store default
values and then update the default values based on observation. In
these embodiments, a limited set of features or transactions may be
available to the user immediately and more features or transactions
may become available (e.g., "unlocked") as the technology "learns"
to passively authenticate the user, such as by detecting and
storing attributes of actions.
[0030] In various embodiments, the technology may enable users to
configure whether/when to enable passive and/or active
authentication/authorization. As examples, a user may specify what
transactions or features should be enabled with passive
authentication.
[0031] As previously indicated, the technology may make
observations by using various hardware and software components to
detect changes to various inputs that are made to the computing
system. Thus, detection and observation are intended to be
synonymous.
[0032] Several embodiments of the facility are described in more
detail in reference to the Figures. The computing devices on which
the described technology may be implemented may include one or more
central processing units, memory, input devices (e.g., keyboard and
pointing devices), output devices (e.g., display devices), storage
devices (e.g., disk drives), and network devices (e.g., network
interfaces). The memory and storage devices are computer-readable
media that may store instructions that implement the technology. In
addition, the data structures and message structures may be stored
or transmitted via a data transmission medium, such as a signal on
a communications link. Various communications links may be used,
such as the Internet, a local area network, a wide area network, or
a point-to-point dial-up connection.
[0033] FIG. 1 is a block diagram illustrating components employed
by the technology in various embodiments. The environment 100 in
which the technology operates can include one or more servers 102a
through 102n, a network 104 (e.g., an intranet or the Internet),
and one or more computing devices, such as mobile computing devices
106a through 106m. Other varieties of computing devices can also be
employed. The mobile computing devices may be handheld devices,
such as mobile telephones. The mobile computing devices may
wirelessly communicate with other devices, such as to communicate
voice, video, or other information, via an antenna 108. The antenna
108 can exchange radiofrequency or other signals with a
corresponding antenna (not shown) associated with the mobile
computing devices.
[0034] FIG. 2 is a flow diagram illustrating a routine performed by
a service upon receiving a request from a client to complete a
transaction. The routine 200 begins at block 202. At block 204, the
routine receives a transaction request, such as from a mobile
computing device. The transaction request may be generated by the
mobile computing device when the user or some other entity
initiates a transaction. In various embodiments, the transaction
may be completely performed at the mobile computing device or may
require exchange information with a service. As an example, the
routine may be invoked by the mobile computing device when the
mobile computing device receives a request to execute an
application. As another example, the routine may be invoked by a
service when it receives a request to complete a financial
transaction. At block 206, the routine determines a confidence
level that may be required to complete the transaction. At block
208, the routine transmits a request for the identified confidence
level to the component that transmitted the transaction request. A
confidence level may be a threshold level of confidence that is
required for the transaction to be automatically authorized without
requiring the user to be actively authenticated. Alternatively, the
routine may transmit indications of one or more confidence factors
to the component that transmitted the transaction request.
Confidence factors may be specific factors that are acceptable,
such as fingerprints, iris scans, signatures, etc. At block 209,
the routine receives from the component that transmitted the
transaction request a response providing an indication of the
confidence level or confidence factors that have been verified. At
decision block 210, the routine determines whether the received
confidence level or factors are acceptable (e.g., exceed a
specified threshold). If the confidence level or factors are
acceptable, the routine continues at block 212. Otherwise, the
routine continues at block 214. At block 212, the routine completes
the transaction. The routine then returns at block 216. At block
214, the routine denies the transaction and may return an error to
the component that transmitted the transaction request. The routine
then returns at block 216.
[0035] Those skilled in the art will appreciate that the logic
illustrated in FIG. 2 and described above, and in each of the flow
diagrams discussed below, may be altered in a variety of ways. For
example, the order of the logic may be rearranged, substeps may be
performed in parallel, illustrated logic may be omitted, other
logic may be included, etc. Moreover, some or all of the logic or
substeps may be performed by one or more devices other than a
specified device. For example, substeps may occur on a mobile
computing device, client computing device, server computing device,
etc.
[0036] FIG. 3 is a flow diagram illustrating a routine performed by
a computing system to observe confidence factors. The routine 300
begins at block 302. At block 304, the routine receives an event
for a confidence factor. As examples, the routine may receive
events indicating that the user has picked up a mobile phone, the
user has rotated the mobile phone, the present temperature at
various points on the mobile phone, the user's usage patterns on
the computing device, etc. At block 306, the routine observes the
confidence factor. As an example, the routine may observe values at
various sensors, accelerometers, keyboard, stylus, or other input
devices. At block 308, the routine stores the search confidence
factors, such as in a data structure stored in memory. At block
310, the routine returns.
[0037] FIG. 4 is a flow diagram illustrating a routine performed by
a computing system to compute a confidence level. The routine 400
may be invoked to compute a confidence level, such as when prompted
by a service or an application. The routine begins at block 402. At
block 404, the routine sets a confidence level to an initial level,
such as a default level. In the loop of blocks 406-412, the routine
modifies the confidence level based on each confidence factor. At
block 406, the routine selects a confidence factor, such as from a
list of observed confidence factors. At block 408, the routine
checks the selected confidence factor, such as by invoking a
subroutine and providing the selected confidence factor to the
subroutine. A subroutine for checking the selected confidence
factor is described in further detail below in relation to FIG. 7.
At block 410, the routine modifies the confidence level based on a
value returned by the subroutine for checking the selected
confidence factor. As an example, routine may increase the
confidence level if the factor is indicated to be geographical
location or name of a network to which the computing device has
connected. The routine selects another confidence factor at block
412. At block 414, the routine returns.
[0038] FIG. 5 is a flow diagram illustrating a routine performed by
a computing system to provide a confidence level. The routine 500
may be invoked to provide a confidence level. The routine begins at
block 502. At block 504, the routine receives a request for a
confidence level. At block 506, the routine computes or retrieves a
confidence level, such as by invoking the subroutine. As an
example, the routine may invoke the routine described above in
relation to FIG. 4 or may invoke the routine described below in
relation to FIG. 6. At block 508, the routine returns the computed
or retrieved confidence level.
[0039] FIG. 6 is a flow diagram illustrating a routine performed by
a computing system to provide confidence factors. The routine 600
may be invoked to provide a list of confidence factors and
associated observations. The routine begins at block 602. At block
604, the routine receives a request for confidence factors. At
block 606, the routine retrieves the confidence factors. In various
embodiments, the routine may receive a list of the confidence
factors that it is to retrieve and provide. In various embodiments,
the routine may provide the complete list of confidence factors. At
block 608, the routine provides the confidence factors. At block
610, the routine returns.
[0040] FIGS. 7A and 7B are flow diagrams illustrating a routine
performed by a computing system to check selected confidence
factors. The routine may compare attributes of a presently observed
action with previously stored attributes of a similar action.
Attributes can include inputs observed from components that provide
input to the computing system, e.g., accelerometer inputs,
touch/pressure sensor inputs, temperature inputs, global
positioning system (GPS) inputs, etc. Presently observed attributes
can be substantially equivalent to previously stored attributes
when the differences are negligible. As an example, there may be
temperature variations between fingers, but overall the fingers
exhibit similar temperatures to those measured previously. The
inputs may be considered as a group (e.g., temperatures for all
fingers) or individually (e.g., temperatures for each finger).
[0041] The routine 700 begins at block 702. FIG. 7A indicates
connectors A. and B. These connectors connect the flow of the
routine to connectors A. and B., respectively, illustrated in FIG.
7B. At block 704, the routine receives an indication of a
confidence factor.
[0042] At decision block 706, the routine determines whether the
indicated confidence factor is a phone number and the phone number
is listed in a list of phone numbers, such as in a list of contacts
or telephone numbers previously entered regularly or several times.
If so, the routine continues at block 722. Otherwise, the routine
continues at decision block 708.
[0043] At decision block 708, the routine determines whether the
indicated confidence factor is heat (or temperature) and the
observed heat that is presently applied by the user is comparable
to historically observed heat applied by the user. The heat may be
observed by checking heat sensors that may be attached to the
computing device. As an example, a mobile phone may have one or
more heat sensors that each measure heat applied by a user's hand.
If the observed heat is comparable to historically observed heat,
the routine continues at block 722. Otherwise, the routine
continues at decision block 710.
[0044] At decision block 710, the routine determines whether the
indicated confidence factor is physical use and one or more
accelerometers associated with the computing device provide inputs
that are comparable to historical physical use indicated by the
accelerometers. The accelerometers may measure how the user
interacts with the computing device, such as when picking it up,
putting it down, and so forth. If the observed use is consistent
with historically observed use, the routine continues at block 722.
Otherwise, the routine continues at decision block 712.
[0045] At decision block 712, the routine determines whether the
indicated confidence factor is touch and touch inputs are presently
providing information that are comparable to historically observed
information from the touch inputs. The touch inputs may be received
from touch sensitive sensors associated with the computing device.
If the observed text inputs are consistent with historically
observed touch inputs, the routine continues at block 722.
Otherwise, the routine continues at decision block 714 (illustrated
in FIG. 7B).
[0046] Turning now to FIG. 7B, at decision block 714, the routine
determines whether the indicated confidence factor is location and
a GPS signal indicates that the computing system is presently
located in an area in which the user has previously operated the
computing system. As an example, when the computing system is in an
area in which the user has never previously used the computing
system, the confidence level may be low that the previously known
user is presently using the computing system. If the location is in
an area in which the user has previously used a computing system,
the routine continues at block 722. Otherwise, the routine
continues at decision block 716. Other location-related inputs can
also (or instead) be applied, such as by identifying available
wireless local area networks or devices connected thereto,
recognizing the surroundings using a camera, etc.
[0047] At decision block 716, the routine determines whether the
indicated confidence factor is co-presence and another device is
proximate to the computing system. As an example, when a user has a
mobile device in one pocket and car keys (previously registered
with the mobile device) in another pocket, it is likely that the
user is the known owner of the mobile device. The car keys may have
an embedded component, such as a radiofrequency identification
chip, that enables the mobile device to identify the car keys (or
any other co-present device that is registered). If the registered
co-present device is proximate, the routine continues at block 722.
Otherwise, the routine continues at decision block 718.
[0048] At decision block 718, the routine determines whether the
identified confidence factor is vision and the image comparison is
acceptable. As an example, the routine may determine whether the
user's face is recognizable, the surroundings are recognizable,
etc. The computing system may employ an attached camera to make
this visual observation. If the image comparison is acceptable, the
routine continues at block 722. Otherwise, the routine continues at
block 720.
[0049] At block 720, the routine decreases the confidence level
because none of the indicated confidence factors was acceptable.
The routine then returns the confidence level at block 726.
[0050] At block 722, the routine sets a weight based on the factor
that was acceptable. At block 724, the routine increases the
confidence level. In some embodiments, the routine may employ
weights for each of the confidence factors (and not just one) and
compute an overall weighted confidence level. The routine then
returns the computer confidence level at block 726.
[0051] Historical information employed by the routine may be stored
in the computing device or elsewhere. If stored elsewhere, the
computing device may access the historical information via a
network connection.
[0052] FIG. 8 is a block diagram illustrating components employed
by the technology in various embodiments. A computing system 802,
such as a mobile computing device, may include a processor 804, a
memory 806, an operating system 808, and one or more applications
810. An application may require authentication of the user or send
a request to a service via a network connection (not illustrated)
that requires authentication of the user.
[0053] The computing system may also include touch/pressure sensors
812, heat sensors 814, accelerometers 816, cameras 818, fingerprint
readers 820, and writing analyzers 822. The touch/pressure sensors
may determine touch or pressure points around the body of the
computing system. The heat sensors may sends heat at one or more
points around the body of the computing system. The accelerometers
may determine how the computing system is picked up, moved, etc.,
by the user. An accelerometer can be an electromechanical device
that measures acceleration forces, e.g., static forces or dynamic
forces. The cameras may observe the user's face, the surroundings,
etc. The fingerprint readers may read the user's fingerprints. The
writing analyzers may analyze how the user writes, such as by using
a stylus. The computing system may also include comparators 824.
Comparators may be configured to compare presently observable
attributes (e.g., heat, pressure, motion, etc.) to previously
stored attributes. Although the components are described in plural,
computing systems may use one of each type of component, or just
some of the components.
[0054] Various embodiments of the technology are now described. The
embodiments may be operated independently or may be combined.
[0055] The technology can include a method performed by a computing
system for passively authenticating a user, comprising: observing
an attribute of an action; comparing the observed attribute of the
action to a previously stored attribute of a similar action;
determining whether the observed attribute is substantially
equivalent to the previously stored attribute of the similar
action; and if the observed attribute is substantially equivalent
to the previously stored attribute of the similar action, passively
authenticating the user without requiring the user to actively
authenticate. The action can be moving the computing system to a
location that is identifiable by the computing device. The
observing can include capturing an image of surroundings using a
camera. The observing can include receiving GPS location
information. The observing can include identifying a wireless local
area network connection. The action can be making a telephone call.
The attribute when making a telephone call can be a telephone
number to which the telephone call is made and the previously
stored attribute can be a telephone number stored in a list of
contacts. The action can be detecting temperature. The action can
be detecting motion. The action can be detecting pressure. The
action can be detecting co-presence of another device. The action
can be recognizing a face. The method can include setting a
confidence level based on two or more comparisons of attributes of
actions and passively authenticating the user when the confidence
level exceeds a specified threshold confidence level.
[0056] The technology can include a computer-readable medium
storing computer-executable instructions that, when executed,
perform a method of passively authenticating a user. The method can
comprise: setting a confidence level to a default value;
identifying a set of confidence factors; for each identified
confidence factor, computing a confidence and modifying the
confidence level based on the computed confidence; and if the
modified confidence level exceeds a specified threshold, passively
authenticating the user without requiring the user to actively
authenticate. The method can include setting a weight for each
identified confidence factor. The modifying can be based on the
weight. The method can include increasing the confidence level upon
receiving a signal from a proximate computing device that has also
authenticated the user.
[0057] The technology can include a system for passively
authenticating a user, comprising: an application that initiates a
request; and a comparator component that is configured to compare
an observed input to a previously stored input without prompting
the user to provide the observed input and, if the comparison is
substantially equivalent, passively authenticates the user so that
the initiated request can be satisfied. The system can include a
server component that satisfies the request. The application may
satisfy the request if the user is passively authenticated; and if
the user could not be passively authenticated, can prompt the user
for authentication credentials so that the user can be actively
authenticated.
[0058] Many authentication schemes are "active" in that they
require the user to provide a secret shared with the computing
system, such as a password. However, active authentication gets in
the way of completing simple tasks on mobile computing systems,
such as making a local call using a "smart" phone that is locked to
comply with corporate security policies. The technology can employ
passive authentication to authenticate a user based on the user's
observed behavior. The user's authentication level can increase or
decrease over time based on the user's observed actions, and
applications/services can determine whether or not to satisfy a
request or complete a transaction based on the present
authentication level.
[0059] Confidence level and authentication level can be synonymous
in various embodiments. Although embodiments relating to passive
authentication are described, the embodiments may also apply
equally to passive authorization.
[0060] Although the subject matter has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the subject matter defined in the appended
claims is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the claims.
Accordingly, the invention is not limited except as by the appended
claims.
* * * * *