U.S. patent application number 15/411699 was filed with the patent office on 2017-05-11 for location and device based student access control.
The applicant listed for this patent is Apollo Education Group, Inc.. Invention is credited to Sharad Gupta, Raghunadha Konda, Balaji Nidadavolu, Rajaa Mohamad Abdul Razack, Pavan Aripirala Venkata.
Application Number | 20170134391 15/411699 |
Document ID | / |
Family ID | 56888679 |
Filed Date | 2017-05-11 |
United States Patent
Application |
20170134391 |
Kind Code |
A1 |
Razack; Rajaa Mohamad Abdul ;
et al. |
May 11, 2017 |
LOCATION AND DEVICE BASED STUDENT ACCESS CONTROL
Abstract
Techniques are described for controlling access to an online
service by a one or more authentication mechanisms based on device,
browser, or location, or a combination of the three. A method
comprises receiving a request to access a service, receiving, in
association with the request, a first access mechanism, receiving a
first and second level of authentication associated with the user
requesting the service, updating authenticated-mechanism data to
indicate that the first access mechanism is an authenticated access
mechanism for the particular user, receiving a second request to
access the service, in response to receiving a second request,
determining whether the second access mechanism is an authenticated
access mechanism for the particular user, upon determining that the
second access mechanism is not an authenticated mechanism,
requesting a second level of authentication for the particular
user, otherwise granting access.
Inventors: |
Razack; Rajaa Mohamad Abdul;
(Cupertino, CA) ; Venkata; Pavan Aripirala;
(Fremont, CA) ; Gupta; Sharad; (Karnataka, IN)
; Konda; Raghunadha; (Karnataka, IN) ; Nidadavolu;
Balaji; (Karnataka, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Apollo Education Group, Inc. |
Phoenix |
AZ |
US |
|
|
Family ID: |
56888679 |
Appl. No.: |
15/411699 |
Filed: |
January 20, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14657936 |
Mar 13, 2015 |
9565183 |
|
|
15411699 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/0876 20130101;
H04L 63/107 20130101; H04W 12/0802 20190101; H04W 12/0605 20190101;
H04L 2463/082 20130101; H04L 63/083 20130101; H04L 63/10 20130101;
H04W 4/021 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04W 12/08 20060101 H04W012/08; H04W 4/02 20060101
H04W004/02; H04W 12/06 20060101 H04W012/06 |
Claims
1. A method comprising: maintaining, on a storage device, first
time information and first location information of a most recent
access to a service by a particular user; receiving a subsequent
request to access the service; receiving, in association with the
subsequent request, authentication information for the particular
user; in response to receiving the subsequent request: determining
second time information and second location information associated
with the subsequent request; determining, based on the first time
information, the second time information, the first location
information, and the second location information, whether it is
feasible for the particular user to have travelled from a first
location associated with the first location information to a second
location associated with the second location information in an
amount of time that lapsed between the first time information and
the second time information; and responsive to determining that it
is not feasible for the particular user to have travelled from the
first location to the second location in the amount of time,
performing at least one of: denying the subsequent request;
granting the subsequent request only after receiving additional
authentication information in association with the subsequent
request.
2. The method of claim 1, wherein the subsequent request is
denied.
3. The method of claim 1, wherein the subsequent request is granted
after receiving additional authentication information in
association with the second request.
4. The method of claim 1, wherein the most recent access to the
service has concluded before receiving the subsequent request to
access the service.
5. The method of claim 1, wherein the most recent access to the
service is accessing the service when the subsequent request is
received and the method further comprises: receiving, in
association with the subsequent request, an indication to grant the
subsequent request and conclude the most accent access.
6. The method of claim 1, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises determining the second
location, at least in part, using HTML, location data associated
with the particular user's computing device.
7. The method of claim 1, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises determining the second
location, at least in part, from known locations of one or more
WiFi hotspots associated with the particular user's computing
device.
8. The method of claim 1, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises determining the second
location, at least in part, from known locations of one or more
cellular towers associated with the particular user's computing
device.
9. The method of claim 1, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises: determining, based on
the first time information, the second time information, the first
location information, and the second location information, an
average speed value; comparing the average speed value with a
pre-defined average speed value; if the average speed value is
lower than the pre-defined average speed value, determining that it
is feasible for the particular user to have travelled from the
first location to the second location; and if the average speed
value is higher than the pre-defined average speed value,
determining that it is not feasible for the particular user to have
travelled from the first location to the second location.
10. The method of claim 1, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises: determining a travel
time between the first location information and the second location
information; determining, based on the first time information and
the second time information, whether the travel time may be
satisfied; if the travel time may be satisfied, determining that it
is feasible for the particular user to have travelled from the
first location to the second location; and if the travel time may
not be satisfied, determining that it is not feasible for the
particular user to have travelled from the first location to the
second location.
11. The method of claim 1, further comprising: before determining
whether it is feasible for the particular user to have travelled
from the first location to the second location and in response to
receiving the subsequent request: determining whether the
subsequent request originates from a computing device corresponding
to an authenticated access mechanism, wherein the authenticated
access mechanism comprises a particular computing device that
previously satisfied a first level of authentication and a second
level of authentication; responsive to the subsequent request
originating from the authenticated access mechanism, allowing the
subsequent request to proceed without receiving, in association
with the subsequent request, the second level of authentication;
and responsive to the subsequent request not originating from the
authenticated access mechanism, allowing the computing device to
access the service only after the second level of authentication is
provided in association with the subsequent request.
12. The method of claim 11, wherein the authenticated access
mechanism includes information identifying: a device; a combination
of device and browser; or a combination of device, browser and
location.
13. A system comprising: one or more processors; and a storage
storing instructions which, when executed by the one or more
processors, cause the one or more processors to perform operations
comprising: maintaining, on a storage device, first time
information and first location information of a most recent access
to a service by a particular user; receiving a subsequent request
to access the service; receiving, in association with the
subsequent request, authentication information for the particular
user; in response to receiving the subsequent request: determining
second time information and second location information associated
with the subsequent request; determining, based on the first time
information, the second time information, the first location
information, and the second location information, whether it is
feasible for the particular user to have travelled from a first
location associated with the first location information to a second
location associated with the second location information in an
amount of time that lapsed between the first time information and
the second time information; and responsive to determining that it
is not feasible for the particular user to have travelled from the
first location to the second location in the amount of time,
performing at least one of: denying the subsequent request;
granting the subsequent request only after receiving additional
authentication information in association with the subsequent
request.
14. The system of claim 13, wherein the most recent access to the
service has concluded before receiving the subsequent request to
access the service.
15. The system of claim 13, wherein the most recent access to the
service is accessing the service when the subsequent request is
received and the method further comprises: receiving, in
association with the subsequent request, an indication to grant the
subsequent request and conclude the most accent access.
16. The system of claim 13, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises determining the second
location, at least in part, using HTML, location data associated
with the particular user's computing device.
17. The system of claim 13, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises determining the second
location, at least in part, from known locations of one or more
WiFi hotspots associated with the particular user's computing
device.
18. The system of claim 13, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises determining the second
location, at least in part, from known locations of one or more
cellular towers associated with the particular user's computing
device.
19. The system of claim 13, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises: determining, based on
the first time information, the second time information, the first
location information, and the second location information, an
average speed value; comparing the average speed value with a
pre-defined average speed value; if the average speed value is
lower than the pre-defined average speed value, determining that it
is feasible for the particular user to have travelled from the
first location to the second location; and if the average speed
value is higher than the pre-defined average speed value,
determining that it is not feasible for the particular user to have
travelled from the first location to the second location.
20. The system of claim 13, wherein determining whether it is
feasible for the particular user to have travelled from the first
location to the second location comprises: determining a travel
time between the first location information and the second location
information; determining, based on the first time information and
the second time information, whether the travel time may be
satisfied; if the travel time may be satisfied, determining that it
is feasible for the particular user to have travelled from the
first location to the second location; and if the travel time may
not be satisfied, determining that it is not feasible for the
particular user to have travelled from the first location to the
second location.
Description
BENEFIT CLAIMS
[0001] This application claims the benefit as a divisional of
application Ser. No. 14/657,936, filed Mar. 13, 2015 the entire
contents of which is hereby incorporated by reference as if fully
set forth herein, under 35 U.S.C. .sctn.120. The applicant(s)
hereby rescind any disclaimer of claim scope in the parent
application(s) or the prosecution history thereof and advise the
USPTO that the claims in this application may be broader than any
claim in the parent application(s).
FIELD OF THE INVENTION
[0002] The present invention relates to methods and systems for
controlling access to online services, and in particular, for
implementing access controls by means of geolocation and
geofencing, as well as by only permitting access from a particular
device/browser combination.
BACKGROUND
[0003] One way to restrict access to online content or services is
to use username/password authentication. Username/password
authentication is easily thwarted, however, when unauthorized users
are told or otherwise obtain the username/password of authorized
users.
[0004] In some online environments, such as online education, it is
particularly important to ensure that the person using log-in
credentials is the actual person that was provided those log-in
credentials. For example, the integrity of tests that are
administered online would be compromised if one student takes the
test under another student's log-in credentials. Therefore, a need
exists for an additional method of authentication that helps ensure
that the person using an online service is the person that the
online service believes is using the online service.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] In the drawings:
[0006] FIG. 1 is a block diagram that depicts an example network
arrangement for a location and device based student access,
according to embodiments.
[0007] FIG. 2 depicts a flow chart showing the initial registration
and configuration of the challenge questions.
[0008] FIG. 3 depicts a flow chart showing device/browser based
access control.
[0009] FIG. 4 depicts a flow chart showing location based access
control.
[0010] FIG. 5 is a block diagram of a computer system on which
embodiments may be implemented.
DETAILED DESCRIPTION
[0011] In the following description, for the purposes of
explanation, numerous specific details are set forth in order to
provide a thorough understanding of the present invention. It will
be apparent, however, that the present invention may be practiced
without these specific details. In other instances, well-known
structures and devices are shown in block diagram form in order to
avoid unnecessarily obscuring the present invention.
GENERAL OVERVIEW
[0012] Methods and systems are provided for controlling access to
online activities, for example online exams and the like. A student
can only be present in one place at a given time. They therefore
cannot participate in two different online classroom activities at
the same time. However, current authentication methods do not
ensure that a student's identity has not been compromised.
Additionally, an online activity provider may require a method of
verifying that only the registered student--and not someone who
possesses the login credentials--is participating in a given online
classroom activity.
[0013] The administrator of an online service, for example an exam,
may wish to restrict access to the service to a single device, a
single device/browser combination, or a single
device/browser/location combination To accomplish this, one or more
access mechanisms can be defined. For example, an authentication
mechanism can be a location access control, a device/browser access
control, a user id/password control, or any other mechanism
suitable for authenticating a user, In one embodiment, one or more
access mechanisms can be combined to improve the authentication
even further, by being arranged in levels--for example, one access
mechanism can comprise the first authentication level, another
access mechanism can comprise the second authentication level, and
so on. If a student taking part in such an activity attempts to log
in for a second time, using for example a different device, a
second authentication mechanism is used to verify their identity to
ensure the login is not fraudulent. If the student successfully
confirms his identity by the second authentication mechanism, they
can then be offered a choice between (a) being granted access to
the activity on his current device (thereby ceasing activity on the
previous device), or (b) continuing access on the previous device
(thereby being denied login on the current device). Additionally,
access may be controlled on the basis of comparing the time and
location of an online session with the time and location of a
previous session, and determining whether it is possible for a user
to have travelled the distance between the location of the current
session and the location of the previous session. If the travel is
not possible, and the same user ID was used for both sessions, then
the second session is not allowed to proceed.
Client/Server Architecture
[0014] Client devices 110A-110C may be implemented by any type of
computing device that is communicatively connected to network 120.
Example implementations of client devices 110A-110C include,
without limitation, workstations, personal computers, laptop
computers, personal digital assistants (PDAs), tablet computers,
cellular telephony devices such as smart phones, and any other type
of computing device.
[0015] In network arrangement 100, each of the client devices
110A-110C is configured with a respective web browser 112A-112C
that may access tutoring service 132. Web browsers 112A-112C may be
any web browser capable of running on the devices 110A-110C, such
as Firefox, Safari, Chrome and so on. Client devices 110A-110C may
be configured with other mechanisms, processes and functionalities,
depending upon a particular implementation.
[0016] Further, client devices 110A-110C are each communicatively
coupled to a display device (not shown in FIG. 1) for displaying
graphical user interfaces. Such a display device may be implemented
by any type of device capable of displaying a graphical user
interface. Example implementations of a display device include a
monitor, a screen, a touch screen, a projector, a light display, a
display of a tablet computer, a display of a telephony device, a
television, etc.
[0017] Network 120 may be implemented with any type of medium
and/or mechanism that facilitates the exchange of information
between client devices 110A-110C and server device 130.
Furthermore, network 120 may facilitate use of any type of
communications protocol, and may be secured or unsecured, depending
upon the requirements of a particular embodiment.
[0018] Server device 130 may be implemented by any type of
computing device that is capable of communicating with client
devices 110A-110C over network 120. In a network arrangement 100,
server device 130 is configured with an online service 132, which
may be part of a cloud computing service. Functionality attributed
to online service 132 may also be performed on client devices
110A-110C, according to embodiments. Server device 130 may be
configured with other mechanisms, processes and functionalities,
depending upon a particular implementation.
[0019] Server device 130 is communicatively coupled to database
140. As shown in FIG. 1, database 140 includes various data
elements that can be used to tailor the online service 132 for the
individual needs of each user at respective client devices
110A-110C, as discussed in further detail below, for example,
authenticated mechanism data and associated information, location
data, and user data. These various types of data are described in
greater detail below. Database 140 may reside in any type of
storage, including volatile and non-volatile storage (e.g., random
access memory (RAM), one or more hard or floppy disks, main memory,
etc.), and may be implemented by multiple logical databases. The
storage on which database 140 resides may be external or internal
to server device 130.
[0020] Any of browsers 112A-112C and online service 132 may receive
and respond to Application Programming Interface (API) calls,
Simple Object Access Protocol (SOAP) messages, requests via
HyperText Transfer Protocol (HTTP), HyperText Transfer Protocol
Secure (HTTPS), Simple Mail Transfer Protocol (SMTP), or any other
kind of communication. Further, any of browsers 112A-112C and
online service 132 may send one or more of the following over
network 120 to one of the other entities: information via HTTP,
HTTPS, SMTP, etc.; XML data; SOAP messages; API calls; and other
communications according to embodiments.
[0021] In an embodiment, each of the processes described are
performed automatically and may be implemented using one or more
computer programs, other software elements, and/or digital logic in
any of a general-purpose computer or a special-purpose computer,
while performing data retrieval, transformation, and storage
operations that involve interacting with and transforming the
physical state of memory of the computer.
Authentication Mechanism Configuration
[0022] FIG. 2 is a flow chart that depicts initial registration and
configuration of the second authentication mechanism. At step 200,
a user 101 registers for access to an online service 132 using a
first authentication mechanism, for example, a user name and
password, or any other user authentication mechanism. The online
classroom activity can be, for example, an exam, a tutorial, or any
other kind of online activity.
[0023] At step 205, it is determined whether the user 101 has
previously provided authentication information for a second
authentication mechanism 230. This determination may be made, for
example, by examining database 140 to determine if authentication
information for the second authentication mechanism 230 has been
associated with the user 101. Upon determining that authentication
information for the second authentication mechanism has been
associated with the user, the method proceeds to step 250 and
permits access to the service.
[0024] Upon determining that authentication information for the
second authentication mechanism has not been associated with the
user, at step 210 the user 101 is prompted to for authentication
information for the second authentication mechanism 230. For
example, in the case where the second authentication mechanism is a
"challenge question" system, the authentication information can
comprise one or more challenge questions and associated responses.
In one embodiment, the challenge questions can be pre-selected, and
the user 101 can be prompted to provide answers thereto. In another
embodiment, the challenge questions can also be written by the
user, with the user also writing the responses thereto.
Additionally, or alternatively, the second authentication mechanism
can comprise a biometric identification device, a smart card, or
any other authentication mechanism that can confirm the identity of
the user 101. The second authentication method should be one that
differs from the first authentication mechanism. The second
authentication mechanism only needs to be configured once for each
user. Once authentication information of a user has been obtained
for the second access mechanism 230, the information can be
permanently stored, for example on the database 140 and retrieved
when necessary to confirm the identity of a user 101.
[0025] In one embodiment, an online activity can permit
simultaneous access from different devices, or different browsers
on the same device. If the online activity does not permit
simultaneous access, the properly authenticated user is prompted to
choose the device on which he or she wishes to participate in the
online activity, and the other device is thereby logged out.
Device/Browser Authentication Mechanism
[0026] According to one embodiment, when a user attempts to obtain
access to an online service, the online service determines whether
the device/browser combination that is being used by the user is
"known". For known device/browser combinations, authentication
using a first authentication mechanism is sufficient. On the other
hand, for unknown device/browser combinations, authentication using
a second authentication mechanism, or both the first and second
authentication mechanism, is required. In one embodiment, a
device/browser combination is "known" relative to a user if that
user has previously used that same device/browser combination to
access the online service.
[0027] FIG. 3 is a flow chart that depicts the steps to determine
whether to grant a user 101 access to an online service 132, where
the authentication process takes into account the device/browser
combination that is being used by the user 101. For the purpose of
explanation, it shall be assumed that user 101 is using client
device 110A and browser 112A to sign in to online service 132, and
that device 110A/browser 112A are associated with a unique
device/browser identifier (UDBI) of UDBI1. The UDBI can be a
sequence of numbers, or letters, or any other identifier capable of
uniquely identifying a particular device or device/browser
combination. The UDBI can be stored, for example in the database
140 or any other kind of suitable storage device.
[0028] At step 300, user 101 logs in, providing the authentication
information required by the first authentication mechanism (e.g. a
userid/password). According to one embodiment, as part of the login
step, the client device 110A sends to server device 130 the
device/browser identifier UDBI1. At step 305, the server device 130
determines whether the device/browser combination that is being
used by user 101 is a known device/browser combination for user
101. For example, service device 120 may compare UDBI1 with the
UDBIs that are stored in the database 140 for previous sessions by
the same user 101. Step 310 is a binary decision step. If UDBI1
matches any previously stored UDBIs for user 101, in other words,
if the device/browser combination is one that the user 101 has used
before, then the method proceeds to step 350.
[0029] If at step 310, the method determines that UDBI1 is not a
known device/browser combination for user 101, then the method
instead proceeds to step 320, wherein the user 101 is required to
authenticate using a second authentication mechanism.
[0030] As detailed above, the second authentication mechanism can
employ any authentication method, for example a set of one or more
challenge questions, a biometric authentication method, or any
other suitable authentication method. The second authentication
method should differ from the first authentication method. If a
user 101 is successfully authenticated by the second authentication
mechanism at step 330, then the method proceeds to step 340. At
step 340, the user 101 is asked whether the user desires the UDBI
of the user's current device/browser combination to be stored. In
response to an affirmative response at step 340, server device 130
stores UDBI1 in the database 140 in association with user 101.
Alternative, at step 340, the user 101 may also choose to decline
to tag the device/browser combination as a "known device" for user
101. This may occur, for example, if he is borrowing a friend's
device, or if he is attempting to access the service 132 from a
public computer.
[0031] At step 352, the server device 130 determines whether the
service 132 that the user 101 wishes to access allows simultaneous
access from multiple devices or multiple browsers on the same
device. If the service 132 permits simultaneous access, at step
360, access is granted.
[0032] At step 350, if the service 132 does not permit simultaneous
access from multiple devices or browsers, the method proceeds to
step 370. At step 370, the user 101 is prompted to choose between
continuing the activity on the previous device or the current
device. If the user 101 chooses to continue the activity on the
current device, the method advances to step 360 and access is
granted. If the student chooses to continue the activity on the
device he logged in from previously, the method proceeds to step
365 and access to the desired activity is denied.
Device Identifiers
[0033] In FIG. 3, an embodiment was described in which
device/browser combinations were treated as "known" or "unknown",
where unknown device/browser combinations require an additional
level of authentication. In an alternative embodiment, the
known/unknown determination may be performed at the device level,
rather than the device/browser combination level. In such an
embodiment, a device would be treated as "known" if the user had
previously used the device to access the service, even if the
previous access was performed using a different application than
the user is currently using to access the service.
Location Access Control
[0034] FIG. 4 is a flow chart depicting a method of controlling
access to an online activity on the basis of the location. As
before, at step 400, the user 101 logs in and requests access to an
online service 132 using a first authentication method, for example
a conventional access credential such as a username and password.
As before, a second authentication mechanism may be presented at
step 410, for example if the device/browser identifier does not
match any stored device/browser identifier for user 101.
[0035] Proceeding, at step 440, server device 130 obtains location
information and time information pertaining to the current login.
In one embodiment, server device 130 can obtain location
information of the user device from the GPS system on the user
device. In another embodiment, server device 130 the location
information can be obtained from the IP address associated with the
login, by querying the Internet Service Provider on the current
location of the device, or any other suitable method of determining
the current location. In one embodiment, the time information can
be obtained from the system time of the server device 130. Server
device 130 records the location and time information at the end of
a session and stores the information in the database 140. At step
445, server device 130 retrieves location and time information
recorded at the end of the previous login session. At step 450, the
server device 130 determines whether the user 101 could have
plausibly traveled from the location associated with the user's
most recent session with the service to his current location in the
time that has expired since the user's most recent session with the
service. Step 450 can be performed, for example, by comparing the
time and location of the current login to a time and location of
the preceding login. Service device 130 may use a publicly
available service, such as Google Maps, to determine how much time
it takes for a person to travel between the two locations. If
travel is determined to be feasible between the locations in the
time that has lapsed between sessions, the method proceeds to step
460, permitting access to the online activity. If travel is
determined to be unfeasible between the locations in the amount of
time that lapsed between sessions, the method proceeds to step 465
and access is denied.
[0036] Referring back to step 450, in one embodiment the server
device 130 can calculate the distance between the location of the
current login and the location of the previous login using the HTML
location data. In another embodiment, the server device 130 can
determine the location of the device from the known location of a
WiFi hotspots that the device is currently connected to. In another
embodiment, the server device 130 can determine the location of the
device from the known location of a cellular tower that the device
is currently connected to. Server device 130 can then calculate the
time elapsed between the current login and the previous login, by
comparing the current system time with the system time recorded
during the previous login. To determine whether travel between the
locations is possible in the time elapsed, the server device 130
uses the distance and time elapsed values obtained to calculate an
average speed, and compares the calculated speed value to a
pre-defined plausible average speed value. If the calculated speed
value is lower than the pre-defined average speed value, then
travel between the locations is plausible.
[0037] In another embodiment, the server device 130 can calculate
the distance between the location of the current login and the
location of the previous login, and calculate the time elapsed
between the current login and the previous login. To determine
whether travel between the locations is possible in the time
elapsed, the server device 130 uses the values obtained to
calculate an average speed, and compares the calculated speed value
to previously observed average speed values. If the calculated
speed value is lower than the previously observed average speed
values, then travel between the locations is plausible.
[0038] In another embodiment, the server device 130 can query a
public travel site to obtain the travel time between the locations,
using the location of the previous login as the point of departure,
and the location of the current login as the point of arrival. Any
suitable travel site such as Kayak, Travelocity, or the like may be
utilized. Server device 130 can then determine whether travel
between the locations is plausible by comparing the travel time
obtained from the public travel site to the time elapsed between
the current login and the previous login.
Device/Browser/Location Authentication
[0039] In another embodiment, the device/browser access control and
location access control, as detailed above, can be combined to
provide an additional level of authentication. For example, a
location-based access control could be administered following the
device/browser authentication step. Additionally, or alternatively,
the location-based access control could be administered before, or
concurrently with, the device/browser authentication step.
Hardware Overview
[0040] According to one embodiment, the techniques described herein
are implemented by one or more special-purpose computing devices.
The special-purpose computing devices may be hard-wired to perform
the techniques, or may include digital electronic devices such as
one or more application-specific integrated circuits (ASICs) or
field programmable gate arrays (FPGAs) that are persistently
programmed to perform the techniques, or may include one or more
general purpose hardware processors programmed to perform the
techniques pursuant to program instructions in firmware, memory,
other storage, or a combination. Such special-purpose computing
devices may also combine custom hard-wired logic, ASICs, or FPGAs
with custom programming to accomplish the techniques. The
special-purpose computing devices may be desktop computer systems,
portable computer systems, handheld devices, networking devices or
any other device that incorporates hard-wired and/or program logic
to implement the techniques.
[0041] For example, FIG. 5 is a block diagram that illustrates a
computer system 600 upon which an embodiment of the invention may
be implemented. Computer system 500 includes a bus 502 or other
communication mechanism for communicating information, and a
hardware processor 504 coupled with bus 502 for processing
information. Hardware processor 504 may be, for example, a general
purpose microprocessor.
[0042] Computer system 500 also includes a main memory 506, such as
a random access memory (RAM) or other dynamic storage device,
coupled to bus 502 for storing information and instructions to be
executed by processor 504. Main memory 506 also may be used for
storing temporary variables or other intermediate information
during execution of instructions to be executed by processor 504.
Such instructions, when stored in non-transitory storage media
accessible to processor 504, render computer system 500 into a
special-purpose machine that is customized to perform the
operations specified in the instructions.
[0043] Computer system 500 further includes a read only memory
(ROM) 508 or other static storage device coupled to bus 502 for
storing static information and instructions for processor 504. A
storage device 510, such as a magnetic disk, optical disk, or
solid-state drive is provided and coupled to bus 502 for storing
information and instructions.
[0044] Computer system 500 may be coupled via bus 502 to a display
512, such as a cathode ray tube (CRT), for displaying information
to a computer user. An input device 514, including alphanumeric and
other keys, is coupled to bus 502 for communicating information and
command selections to processor 504. Another type of user input
device is cursor control 516, such as a mouse, a trackball, or
cursor direction keys for communicating direction information and
command selections to processor 504 and for controlling cursor
movement on display 512. This input device typically has two
degrees of freedom in two axes, a first axis (e.g., x) and a second
axis (e.g., y), that allows the device to specify positions in a
plane.
[0045] Computer system 500 may implement the techniques described
herein using customized hard-wired logic, one or more ASICs or
FPGAs, firmware and/or program logic which in combination with the
computer system causes or programs computer system 500 to be a
special-purpose machine. According to one embodiment, the
techniques herein are performed by computer system 500 in response
to processor 504 executing one or more sequences of one or more
instructions contained in main memory 506. Such instructions may be
read into main memory 506 from another storage medium, such as
storage device 510. Execution of the sequences of instructions
contained in main memory 506 causes processor 504 to perform the
process steps described herein. In alternative embodiments,
hard-wired circuitry may be used in place of or in combination with
software instructions.
[0046] The term "storage media" as used herein refers to any
non-transitory media that store data and/or instructions that cause
a machine to operate in a specific fashion. Such storage media may
comprise non-volatile media and/or volatile media. Non-volatile
media includes, for example, optical disks, magnetic disks, or
solid-state drives, such as storage device 510. Volatile media
includes dynamic memory, such as main memory 506. Common forms of
storage media include, for example, a floppy disk, a flexible disk,
hard disk, solid-state drive, magnetic tape, or any other magnetic
data storage medium, a CD-ROM, any other optical data storage
medium, any physical medium with patterns of holes, a RAM, a PROM,
and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or
cartridge.
[0047] Storage media is distinct from but may be used in
conjunction with transmission media. Transmission media
participates in transferring information between storage media. For
example, transmission media includes coaxial cables, copper wire
and fiber optics, including the wires that comprise bus 502.
Transmission media can also take the form of acoustic or light
waves, such as those generated during radio-wave and infra-red data
communications.
[0048] Various forms of media may be involved in carrying one or
more sequences of one or more instructions to processor 504 for
execution. For example, the instructions may initially be carried
on a magnetic disk or solid-state drive of a remote computer. The
remote computer can load the instructions into its dynamic memory
and send the instructions over a telephone line using a modem. A
modem local to computer system 500 can receive the data on the
telephone line and use an infra-red transmitter to convert the data
to an infra-red signal. An infra-red detector can receive the data
carried in the infra-red signal and appropriate circuitry can place
the data on bus 502. Bus 502 carries the data to main memory 506,
from which processor 504 retrieves and executes the instructions.
The instructions received by main memory 506 may optionally be
stored on storage device 510 either before or after execution by
processor 504.
[0049] Computer system 500 also includes a communication interface
518 coupled to bus 502. Communication interface 518 provides a
two-way data communication coupling to a network link 520 that is
connected to a local network 522. For example, communication
interface 518 may be an integrated services digital network (ISDN)
card, cable modem, satellite modem, or a modem to provide a data
communication connection to a corresponding type of telephone line.
As another example, communication interface 518 may be a local area
network (LAN) card to provide a data communication connection to a
compatible LAN. Wireless links may also be implemented. In any such
implementation, communication interface 518 sends and receives
electrical, electromagnetic or optical signals that carry digital
data streams representing various types of information.
[0050] Network link 520 typically provides data communication
through one or more networks to other data devices. For example,
network link 520 may provide a connection through local network 522
to a host computer 524 or to data equipment operated by an Internet
Service Provider (ISP) 526. ISP 526 in turn provides data
communication services through the world wide packet data
communication network now commonly referred to as the "Internet"
528. Local network 522 and Internet 528 both use electrical,
electromagnetic or optical signals that carry digital data streams.
The signals through the various networks and the signals on network
link 520 and through communication interface 518, which carry the
digital data to and from computer system 500, are example forms of
transmission media.
[0051] Computer system 500 can send messages and receive data,
including program code, through the network(s), network link 520
and communication interface 518. In the Internet example, a server
530 might transmit a requested code for an application program
through Internet 528, ISP 526, local network 522 and communication
interface 518.
[0052] The received code may be executed by processor 504 as it is
received, and/or stored in storage device 510, or other
non-volatile storage for later execution.
[0053] In the foregoing specification, embodiments of the invention
have been described with reference to numerous specific details
that may vary from implementation to implementation. The
specification and drawings are, accordingly, to be regarded in an
illustrative rather than a restrictive sense. The sole and
exclusive indicator of the scope of the invention, and what is
intended by the applicants to be the scope of the invention, is the
literal and equivalent scope of the set of claims that issue from
this application, in the specific form in which such claims issue,
including any subsequent correction.
* * * * *