Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A restricted web site has features that are selectively exposed to
clients. A screening web site interacts with clients and collects data
about the clients using passive and/or active techniques. The screening
site generates a token for the client, and includes data in the token
identifying the token and describing the client. The token is encoded in
a cookie and saved in the client's web browser. The client subsequently
provides the token to the restricted site. The restricted site validates
the token to ensure that it is legitimate, has not expired, and has not
been used before. The restricted site selects one or more features to
provide to the client based on the data about the client in the token
and/or on other information. If the client does not present a token or
the token is invalid, the restricted site does not expose any features to
the client.

Claims:

1. A method for providing a user with restricted features of a restricted
web site, comprising: providing a restricted web site having a set of
restricted features, the restricted site adapted to: receive from the
user a token having a key incorporated therein; validate the token
received from the user; responsive to a determination that the token is
invalid, provide the user with none of the features in the set of
restricted features; and responsive to a determination that the token is
valid: retrieve data about the user from a database entry using the key
incorporated into the token; determine selected features in the set of
restricted features that the user may access based at least in part on
the data retrieved from the database entry; and provide the selected
features to the user.

Description:

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation of U.S. patent application Ser.
No. 13/079,642, filed Apr. 4, 2011, which is a continuation of U.S.
patent application Ser. No. 11/331,797, filed Jan. 13, 2006, the contents
of which are both hereby incorporated by reference in their entireties.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] This invention pertains in general to network security and in
particular to providing selective access to web sites such as those
conducting electronic commerce.

[0004] 2. Description of the Related Art

[0005] The Internet relies on standard protocols and open systems.
Consider, for example, the World Wide Web, where web sites are identified
by uniform resource locators (URLs) in a standard format. Any client on
the Internet can use a given site's URL to access the site.

[0006] In certain circumstances, however, the operators of a web site
desire to limit the set of clients (and users of the clients) that can
access their site. Further, in some cases the operators want to
completely hide the site from unauthorized clients. For example, the site
can exist as part of a beta test, and the operators might want to
completely hide the site from clients that are not enrolled in the test.
In another example, the site can be part of an electronic commerce
system, and the operators might want to hide or limit site access to only
clients entitled to use the system. It is difficult to hide or restrict a
web site given the open access normally provided by the Internet.

[0007] One way to hide the existence of a web site is through obscurity.
The site can be located at a URL unlikely to be discovered by
unauthorized clients. The URL can be provided to the beta testers or
other limited set of clients that are expected to access the site.
Unfortunately, such URLs are often leaked to the public, making the site
accessible to anyone who learns the URL. It is difficult to change the
URL once it has leaked, because the new URL must be distributed to all of
the authorized clients and any coded logic that makes use of the URL must
also change.

[0008] One common way to restrict access to a web site is to establish
access control at the site. The home page of the site can require that
clients provide valid authentication credentials before allowing access
to the remainder of the site. This solution, of course, exposes the
existence of the site and is not ideal for situations where the site
should remain hidden. Further, requiring authentication credentials
interrupts the control flow for the site and is undesirable. In a beta
test, the site operators would like to test the site using real world
conditions, and forcing an authentication step can disrupt the test if
the production version of the site does not have authentication.
Similarly, the site operators might not want to force an authentication
in the middle of an electronic commerce transaction. Additionally, there
are situations where the site operators desire a hybrid approach that
hides the existence of a site from unauthorized clients yet also requires
authorized clients to present credentials.

[0009] Looking at the issue more generally, site operators sometimes
desire to treat different clients differently, such as by exposing
different feature sets to different clients, either with or without
requiring the clients to present authentication credentials. These
variations are difficult to implement due to the open nature of the
Internet. Accordingly, there exists a need in the art for a way to hide
and/or restrict access to web sites on the Internet that does not suffer
from the deficiencies described above.

BRIEF SUMMARY OF THE INVENTION

[0010] The above need is met by a method, system, and computer program
product that selectively expose features of a restricted web site to a
client. In one embodiment, a screening web site interacts with the client
and selectively provides the client with a token. The restricted web site
receives the token from the client, determines the features to expose in
response, and exposes the determined features to the client.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 is a high-level block diagram of a computing environment
according to one embodiment.

[0012] FIG. 2 is a high-level block diagram illustrating a functional view
of a typical computer system for use as one of the entities illustrated
in the environment of FIG. 1 according to one embodiment.

[0013] FIG. 3 is a high-level block diagram illustrating functional
modules within the screening site of FIG. 1 according to one embodiment.

[0014] FIG. 4 is a high-level block diagram illustrating functional
modules within the restricted site of FIG. 1 according to one embodiment.

[0015] FIG. 5 is a ladder diagram illustrating interactions among the
client, screening site, and restricted site according to one embodiment.

[0016] The figures depict an embodiment of the present invention for
purposes of illustration only. One skilled in the art will readily
recognize from the following description that alternative embodiments of
the structures and methods illustrated herein may be employed without
departing from the principles of the invention described herein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A. Overview

[0017] FIG. 1 is a high-level block diagram of a computing environment 100
according to one embodiment of the present invention. FIG. 1 illustrates
two clients 110A, 110B, a screening web site 112, and a restricted web
site 114, all connected by a network 116. In one embodiment, the
screening web site 112 provides tokens to the clients 110. The clients
110 present the tokens to the restricted site 114, and the restricted
site selectively exposes features of the site to the clients depending
upon the tokens. The use of the token thus allows the restricted site 114
to discriminate among the clients 110 without interfering with the normal
flow of interaction with the site.

[0018] FIG. 1 and the other figures use like reference numerals to
identify like elements. A letter after a reference numeral, such as
"110A," indicates that the text refers specifically to the element having
that particular reference numeral. A reference numeral in the text
without a following letter, such as "110," refers to any or all of the
elements in the figures bearing that reference numeral (e.g. "110" in the
text refers to reference numerals "110A" and/or "110B" in the figures).

[0019] In one embodiment, the client 110 is a computer utilized by an
end-user to communicate with other computers on the network 116. The
computer, for example, can be a personal computer executing a web browser
such as MICROSOFT INTERNET EXPLORER, NETSCAPE BROWSER, or MOZILLA
FIREFOX, that allows the end-user to retrieve and display content from
web servers and other computers on the network 116. In other embodiments,
the client 110 is a network-capable device other than a personal
computer, such as a personal digital assistant (PDA), a cellular
telephone, a pager, a television "set-top box" etc. Although FIG. 1
illustrates two clients 110, embodiments of the present invention can
have thousands or millions of clients.

[0020] In one embodiment, the screening site 112 is a web site at a
location defined by a uniform resource locator (URL). Depending upon the
embodiment, the web site can be located at an address that is
infrequently accessed by most clients, or at an address that is heavily
trafficked by clients (e.g., www.google.com). Clients 110 use the URL to
visit the screening site 112, and the site gathers data about the clients
that visit it. The screening site 112 evaluates the data about the
particular clients 110 and determines whether the clients are allowed to
access the restricted site 114. If a client 110 is allowed access, the
screening site provides the client 110 with a token. In one embodiment,
the token is embedded in a cookie that the screening site 112 installs in
the client's web browser. In some embodiments there are multiple
screening sites 112.

[0021] The restricted site 114 is a web site providing a set of features
to the clients 110. The restricted site 114 selectively exposes only
certain features to certain clients. In one embodiment, the restricted
site 114 uses data in the tokens it receives from the clients 110 to
determine what features to expose. The set of features can include
whether a client 110 can view the site at all, whether the client must
provide authentication credentials, whether the client can use certain
payment options (e.g., credit cards, gift certificates, scrip), etc. In
some embodiments there are multiple restricted sites 114.

[0022] The restricted site 114 can be utilized as part of a beta test of a
web-based application, where the features that are selectively exposed
include the various functions of the application being tested. For
example, the restricted site 114 can be used to test a sign-up system by
only exposing the system to clients who have tokens (thereby preventing
unauthorized clients from even accessing the sign-up form). Similarly,
the restricted site can be used to provide selective access for testing
an application that lacks a sign-up system. The restricted site 114 can
also be used to test interactions among different systems, where one
would not necessarily want the testers to provide authentication
credentials each time they encounter a new system. For example, the
restricted site can be used to test an electronic commerce system having
separate systems for delivering electronic content and for paying for the
content.

[0023] While the screening site 112 and restricted site 114 can be located
at any location on the network 116, in one embodiment both sites are
located within the same network domain. For reasons of security, many web
browsers allow a web site to access only cookies within the same domain
as the site. Thus the screening 112 and restricted 114 sites are within
the same domain so that the restricted site can read the cookies (and
tokens within cookies) placed by the screening site. In other
embodiments, the web browsers may enable cross-domain cookie sharing,
thereby eliminating the need for the sites to share a domain. In still
other embodiments, the screening site 112 does not use cookies to store
the tokens, thereby rendering the issue moot.

II. System Architecture

[0024] FIG. 2 is a high-level block diagram illustrating a functional view
of a computer 200 for use as one of the entities illustrated in the
environment 100 of FIG. 1 according to one embodiment. Illustrated are at
least one processor 202 coupled to a bus 204. Also coupled to the bus 204
are a memory 206, a storage device 208, a keyboard 210, a graphics
adapter 212, a pointing device 214, and a network adapter 216. A display
218 is coupled to the graphics adapter 212.

[0025] The processor 202 may be any general-purpose processor such as an
INTEL x86, SUN MICROSYSTEMS SPARC, or POWERPC compatible-CPU. The storage
device 208 is, in one embodiment, a hard disk drive but can also be any
other device capable of storing data, such as a writeable compact disk
(CD) or DVD, or a solid-state memory device. The memory 206 may be, for
example, firmware, read-only memory (ROM), non-volatile random access
memory (NVRAM), and/or RAM, and holds instructions and data used by the
processor 202. The pointing device 214 may be a mouse, track ball, or
other type of pointing device, and is used in combination with the
keyboard 210 to input data into the computer system 200. The graphics
adapter 212 displays images and other information on the display 218. The
network adapter 216 couples the computer system 200 to the network 116.

[0026] As is known in the art, the computer 200 is adapted to execute
computer program modules. As used herein, the term "module" refers to
computer program logic and/or data for providing the specified
functionality. A module can be implemented in hardware, firmware, and/or
software. In one embodiment, the modules are stored on the storage device
208, loaded into the memory 206, and executed by the processor 202.

[0027] The types of computers 200 utilized by the entities of FIG. 1 can
vary depending upon the embodiment and the processing power required by
the entity. For example, the client 110 can be a personal computer,
cellular telephone, or other consumer electronic device. The screening
112 and restricted 114 sites, in contrast, may run on more powerful
computers and/or multiple computers working together to provide the
functionality described herein.

[0028] FIG. 3 is a high-level block diagram illustrating functional
modules within the screening site 112 according to one embodiment. Those
of skill in the art will recognize that other embodiments can have
different and/or additional modules than the ones shown. In addition, the
functionalities can be distributed among the modules differently than is
described here.

[0029] A web server module 310 serves web pages and other content (such as
cookies) to clients 110 that interact with the screening site 112. The
web server 310 maintains a set of pages encoded in a markup language such
as HTML. The pages contain text, images, code (e.g., JAVASCRIPT) and/or
other content and can be static and/or dynamically generated. In one
embodiment, the web server module 310 serves only the content necessary
to support the operation of the screening site 112. In other embodiments,
in contrast, the web server module 310 supports one or more web sites
serving a wide variety of content.

[0030] A data collection module 312 collects data describing clients 110
and/or end-users that interact with the screening site 112. In one
embodiment, the data collection module 312 includes a passive collection
module 314 and an active collection module 316. The passive collection
module 314 uses passive techniques to gather data. Passive techniques are
techniques that are generally unnoticed by the end-user of the clients
110 and do not require end-user interaction. The data gathered through
passive techniques can include, for example, the IP address of the client
110, the MAC address of the client, and cookies and other information
stored by the client browser that are accessible to the screening site
112 (typically through interactions with the web server module 310). In
addition, passive data include data that are derived or inferred from
other passively-collected data. For example, the client's geographic
location can often be inferred from the client's IP address.

[0031] The active collection module 316 uses active techniques to gather
data. Active techniques are techniques that are noticeable to the
end-users of the clients 110 and may require the end-users' active
participation. For example, active techniques include providing web pages
to a client 110 that ask the end-user to provide information such as a
name, address, age, and the like. In addition, active techniques can
include asking the end-user to provide information that is expected to be
known by only the end-user or by a select group of people, such as
authentication credentials or a beta tester ID. In one embodiment, access
to the screening site 112 is secure, and only clients that supply the
proper authentication credentials to the active collection module 316 are
granted access to the remainder of the screening site.

[0032] In one embodiment, the data collection module 312 stores the
collected data in a database 318 or other data store. The database 318 is
accessible to the other modules in the screening site 112. In one
embodiment, the database 318 is also accessible to other entities on the
network 116, such as the restricted site 114. In one embodiment, each
entry in the database is identified by a key that uniquely identifies the
client 110 and/or end-user.

[0033] A token generation module 318 generates tokens granting access to
the restricted site 114 for the clients 110. In one embodiment, the token
generation module 318 selectively generates the tokens depending upon the
data collected by the data collection module 312. For example, the token
generation module 318 can generate tokens for only clients having a
certain range of IP addresses, or for only clients that provide a correct
password.

[0034] Each token includes a value uniquely identifying itself. In one
embodiment, the value identifying the token is a serial number or other
value that is incremented for each token. In other embodiments, the value
identifying a token is calculated through an algorithm (e.g., the LUHN
formula) that can be validated by an entity that receives the token. The
token also includes a value that specifies a validity period for the
token, such as a timestamp indicating the token's creation date and/or an
expiration date. Further, in one embodiment, the token includes
information collected by the data collection module 312. For example, a
token can include the beta tester ID, client IP address, end-user's name
and/or other such information. Similarly, in one embodiment the token
includes the database key corresponding to the client 110 and/or end-user
receiving the token. The information in the token can also identify the
screening site 112 that issued the token. In one embodiment, the token
and/or selected information within the token are protected using
cryptographic techniques to prevent unauthorized access and/or alteration
of the token.

[0035] The token generation module 318 causes the tokens to be stored at
the clients 110. As mentioned above, one embodiment of the token
generation module 320 encodes the tokens in cookies and stores the
cookies in the clients' web browsers. In other embodiments, the token is
stored in another persistent location in the browser or elsewhere on the
client 110.

[0036] FIG. 4 is a high-level block diagram illustrating functional
modules within the restricted site 114 according to one embodiment. Those
of skill in the art will recognize that other embodiments can have
different and/or additional modules than the ones shown. In addition, the
functionalities can be distributed among the modules differently than is
described here.

[0037] A web server module 410 serves web pages and other content to
clients 110 that interact with the restricted site 112. The web server
module 410 is functionally equivalent to the web server module 310 in the
screening site 112 and, in some embodiments, is the same web server. The
content provided by the web server module 410 depends upon the features
and functionality provided by the restricted site 114. In the embodiment
where the restricted site 114 supports a beta test of a web-enabled
application, the web server module 410 serves content for the
application. In the embodiment where the restricted site 114 supports an
electronic commerce system, the web server module 410 serves content
allowing a client to purchase items and/or perform related transactions.
In one embodiment, the web server module 410 can dynamically select
and/or change the served content in response to information received from
the clients and/or from other modules within the restricted site 114.
This dynamism allows the web server module 410 to selectively expose
different features to different clients.

[0038] A token validation module 412 validates tokens received from
clients 110. Specifically, the token validation module 412 first verifies
that a client 110 has presented a token (e.g., has provided the web
server module 410 with a cookie having a token encoded within it). If the
token is present, the token validation module 412 verifies that the token
is legitimate (e.g., contains a valid ID and has not been altered) and
has not expired. In one embodiment, a token can be used only a single
time, and the token validation module 412 therefore determines whether
the token has been used before. To this end, the token validation module
412 maintains a list or other data structure describing tokens that have
been used already, and adds each new token to the list as it is
encountered.

[0039] A selective access module 414 provides clients with selective
access to the features of the restricted site 114. If the client 110
fails to provide a token, provides an illegitimate token, or provides an
expired token, the selective access module 414 denies the client any
access to the restricted site 114. This denial of access can be made to
appear as if no site exists at the URL referenced by the client 110. For
example, the selective access module 414 can present a web page
containing the familiar "404-Page not found" error message to the client
110. In other embodiments, the selective access module 414 can provide
the client 110 with a web page that describes the reasons for the denial
of access, and/or other information.

[0040] If the client 110 presents a valid token, the selective access
module 414 provides the client 110 with access to a set of features of
the site. In one embodiment, the selective access module 414 maintains a
set of rules or other equivalent logic that describe the features to make
available based on given information about the client and/or end-user.
The features provided to a particular client 110 can depend upon the
information contained within the token presented by that client,
information stored in the database 318 of the data collection module 312
in the screening site 112, and/or other information. In one embodiment,
the selective access module 414 retrieves the database key from the token
and uses it to access information about the client 110 and/or end-user
contained in the data collection module 312 of the screening site 112.

[0041] For example, in an ecommerce example the token can include data
indicating that a client is entitled to use credit cards to pay for
transactions. In response, the selective access module 414 causes the web
server 410 to present the client 110 with web pages that contain credit
card payment options. If the token indicates that the client 110 is not
entitled to use credit cards, the selective access module 414 causes the
web server 410 to send web pages that lack the credit card payment
options, show the options to be unavailable (e.g., the options are
grayed-out), etc.

[0042] In one embodiment, the selective access module 414 provides an
additional layer of security beyond the token by requiring clients 110 to
present valid authentication credentials. For example, the selective
access module 414 can require a client 110 submitting a valid token to
also provide a valid login/password pair. Clients 110 that do not provide
valid authentication credentials are denied access to the remainder of
the restricted site 114.

III. Process/Example

[0043] FIG. 5 is a ladder diagram illustrating interactions among the
client 110, screening site 112, and restricted site 114 according to one
embodiment. In the diagram, time flows from top to bottom and the
horizontal lines represent interactions among entities. Actions performed
by an entity are represented by text boxes. Those of skill in the art
will recognize that other embodiments can contain different and/or
additional interactions and actions, and that the events depicted in FIG.
5 can be performed in different orders.

[0044] Initially, the client 110 requests 510 a token from the screening
site 112, typically by requesting a web page from the site. This request
can occur as part of another event and the client need not visit the site
specifically to get the token. For example, the screening site 112 can be
part of an electronic commerce web site, where the client 110 is visiting
the site in order to purchase an item. The web page that provides the
token can be any one of the multiple web pages that the client 110 is
expected to visit while shopping.

[0045] In response to the client request 510, the screening site 112
collects 512 data about the client using passive and/or active
techniques. The collected data can include, for example, the IP address
of the client and the mailing address of the end-user. The screening site
112 generates 514 a token for the client 110. The token contains a unique
identifying value and a timestamp or other data that can be used to
calculate a validity period. In some embodiments, the token also includes
data describing the client 110, end-user, and/or screening site 112. The
screening site 112 sends 516 the token to the client 110, typically by
encoding the token in a cookie.

[0046] At some point, the client 110 requests a web page from the
restricted site 114. For example, the client 110, while still at the
screening site 112, could be presented with a page of payment options.
This page can include an option that, when selected, takes the client 110
to the restricted site 114. As a consequence of selecting the option,
therefore, the client 110 requests a page from the restricted site. As
part of this interaction, the restricted site 114 receives 518 from the
client 110 the token provided by the screening site 112 (if the token is
present).

[0047] The restricted site 114 validates 520 the token to ensure that it
is legitimate, has not expired, and has not been used before. In
addition, the restricted site 114 determines the set of features to
expose to the client 110. This determination can be based on information
within the token, on information within the data collection database 318,
and/or based on other information. The restricted site 114 provides 524
the client with access to the exposed feature set. If the client 110 does
not present a token, or the token is invalid, the restricted site 114
exposes no features to the client 110 and, in one embodiment, reacts as
if the site does not exist. The client 110 accesses 526 the site 114 and
utilizes the exposed features. For example, the restricted site 114 can
determine from the token that the client 110 is entitled to use credit
cards to pay for transactions. Therefore, the restricted site 114
provides the client 110 with web pages that include credit card payment
options, thereby allowing the client 110 to access the credit card
payment feature.

[0048] The above description is included to illustrate the operation of
the preferred embodiments and is not meant to limit the scope of the
invention. The scope of the invention is to be limited only by the
following claims. From the above discussion, many variations will be
apparent to one skilled in the relevant art that would yet be encompassed
by the spirit and scope of the invention.