Ex Parte Ham et al

Board of Patent Appeals and Interferences

Nov 3, 2010

10477764 (B.P.A.I. Nov. 3, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte MASON L. HAM, AJAY BHATNAGER,
and SCOTT MAXWELL
____________

Appeal 2009-006670
Application 10/477,764
Technology Center 2400
____________

Before JOHN A. JEFFERY, JEAN R. HOMERE, and JAMES R. HUGHES,
Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL1
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-13 and 16-27. Claims 14, 15, 28, and 29 have been
indicated as containing allowable subject matter. Ans. 2-3. We have
jurisdiction under 35 U.S.C. § 6(b). We affirm.

1 The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, or for filing a request for rehearing,
as recited in 37 C.F.R. § 41.52, begins to run from the “MAIL DATE”
(paper delivery mode) or the “NOTIFICATION DATE” (electronic delivery
mode) shown on the PTOL-90A cover letter attached to this decision.
Appeal 2009-006670
Application 10/477,764

2
STATEMENT OF THE CASE
Appellants’ invention logs into and provides access to multiple
computer systems via a network using a single authenticating process (e.g.,
username and password). See generally Abstract. Claims 1 and 2 are
illustrative with key disputed limitations emphasized:
1. A method of permissioning at least one user to access via a
network at least one of a plurality of computer systems by the use of an
access control system, said method comprising the steps of:

a) receiving a user request directed to a selected one of the plurality of
computer systems, the user request including a session identifier;

b) processing the received request as to whether the one user is
authenticated or not to access information held by the selected one computer
system;

c) if the one user is not authenticated as determined in step b),
transmitting a message from the one computer system via the network to the
user requesting the user to communicate with the access control system and
to provide its authentication information to obtain authentication;

d) receiving a communication via the network from the user at the
access control system, the communication bearing the user's session
identifier;

e) processing the received user communication to determine whether
the access control system had previously received the transmitted user's
authentication information;

f) if the access control system had previously received the
authentication information as determined in step e), the access control
system provides and transmits an authentication message via the network to
the user to be redirected to the one computer system; and

Appeal 2009-006670
Application 10/477,764

3
g) the one computer system receiving and processing the
authentication message to permit the user access to information held by the
one computer system.

2. A method performed by a resource on a network, comprising:

receiving a request for a client system to access said resource; and

sending to said client system, information and an instruction for said
client system to send said information to a login server.

The Examiner relies on the following as evidence of unpatentability:
Lin US 6,052,785 Apr. 18, 2000
Win US 6,182,142 B1 Jan. 30, 2001

THE REJECTIONS
1. The Examiner rejected claim 1 under 35 U.S.C. § 102(b) as
anticipated by Lin. Ans. 3-4.2
2. The Examiner rejected claims 2-13 and 16-27 under 35 U.S.C.
§ 102(b) as anticipated by Win. Ans. 4-8.

THE ANTICIPATION REJECTION OVER LIN
Regarding claim 1, the Examiner finds that Lin’s method of enabling
user data access via a network discloses every recited feature including
transmitting a message from a computer system to an unauthenticated user
requesting that user communicate with the access control system and to
provide its authentication information as claimed. Ans. 3-4, 8-9. In this

2 Throughout this opinion, we refer to (1) the Appeal Brief filed February
14, 2008; (2) the Examiner’s Answer mailed May 14, 2008; and (3) the
Reply Brief filed July 2, 2008.
Appeal 2009-006670
Application 10/477,764

4
regard, the Examiner relies on Lin’s server prompting the client with a login
form to obtain a user ID and password which is then passed to a security
server or remote data repository for authentication. Id.
Appellants contend that this position is erroneous since Lin’s server
software 150 (1) obtains the client’s ID and password, and (2) passes this
information to the credential management function 160. App. Br. 19-20;
Reply Br. 2. But Appellants emphasize that Lin’s server software does not
send a message to the client requesting that the client communicate with the
credential management function. Id. The issue before us, then, is as
follows:

ISSUE
Under § 102, has the Examiner erred in rejecting claim 1 by finding
that Lin transmits a message from a computer system to an unauthenticated
user requesting the user communicate with the access control system and to
provide its authentication information?

FINDINGS OF FACT (FF)
1. Lin’s system authenticates clients 102, 104, 106 to access data
managed by network-based back-end data repositories 110, 112, 114 via
middle tier server 108. Lin, col. 1, ll. 7-13; col. 2, ll. 40-62; Fig. 1.
2. Middle-tier server 108 includes server software 150 that (1)
accepts client requests; (2) interprets these requests; and (3) formats and
sends the necessary response. Lin, col. 5, ll. 14-20; Fig. 1.

Appeal 2009-006670
Application 10/477,764

5
3. Web server 150 supports a server to back-end credential
management function 160 that uses a stored hash table for secure back-end
access. The hash table includes data elements such as “User ID,” “Session
ID,” and “Credentials/Password.” Lin, col. 6, ll. 24-66; Figs. 1, 3.
4. After receiving a secure sockets layer (SSL) request for data
access, Lin’s system uses the SSL session ID to access the hash table to
locate previously-stored credentials. If no encrypted credentials are found,
the server prompts the client with a login form for a user ID and password to
authenticate data repository access. The user ID and password are passed to
a security server or remote data repository for authentication. Lin, col. 7, ll.
27-35; Fig. 4 (steps 410-416).

ANALYSIS
Based on the record before us, we find no error in the Examiner’s
anticipation rejection of claim 1 which calls for, in pertinent part,
transmitting a message from a computer system to an unauthenticated user
requesting the user communicate with the access control system and to
provide its authentication information.
In short, we see no error in the Examiner’s reliance on Lin’s (1)
prompting the client with a login form for a user ID and password, and (2)
passing the user’s information to a security server or remote data repository
for authentication. Ans. 8-9; FF 4. First, this information obtained via a
“message” sent to the user as a login form if the user’s credentials are not
found (FF 4)—a circumstance indicating that the user is not authenticated.
Appeal 2009-006670
Application 10/477,764

6
That is, the purpose of this login form (i.e., “message”) is to request that the
user provide their user ID and password via the form so that this information
can be passed to the appropriate server for authentication. See id.
Despite Appellants’ contention that, after obtaining the user’s ID and
password via the form, Lin’s server software 150 passes this information to
the middle tier server’s credential management function 160 (App. Br. 19-
20; Reply Br. 2), it is unclear how the user’s ID and password acquired via
the login form is passed to the security server or remote data repository for
authentication—server-based entities distinct from the credential
management function. See FF 4.
Nevertheless, even assuming, without deciding, that Lin’s middle tier
server’s software 150 functions essentially as an intermediary between the
clients and the “access control system” (e.g., the security server, remote data
repository, and/or access control functionality of the middle-tier server
including the credential management function) regarding transferring data
between these entities, nothing in claim 1 precludes such an intermediary-
based relay of information from the client to the access control system. That
is, nothing in the claim requires a request that the user directly communicate
with the access control system (i.e., without an intermediary relaying such
information). Regardless of whether the client directly or indirectly
communicates with the access control system responsive to this request, the
client nonetheless communicates with that system. And that is all claim 1
requires in this regard.
We are therefore not persuaded that the Examiner erred in rejecting
claim 1.

Appeal 2009-006670
Application 10/477,764

7
THE ANTICIPATION REJECTION OVER WIN
Regarding representative claim 2, the Examiner finds that Win (1)
receives a request for a client system to access a resource, and (2) sends to
the client system (a) information pertaining to the username and password,
and (b) an instruction for the client system to send the information to a login
server as claimed. Ans. 4-5, 10.
Appellants argue that while Win’s access server sends a cookie to the
user’s browser upon authentication, and the user’s browser sends this cookie
to a protected web server when the user selects a resource, the access server
does not send an instruction to the user’s browser, let alone instruct the
client system to send the information to a login server as claimed. App. Br.
20-21. Appellants add that since the user in Win selects the resource after
login, Win does not disclose the recited sequence of (1) receiving a request
for a client system to access a resource, and (2) sending to the client system
information and an instruction for the client system to send the information
to a login server as claimed. App. Br. 21. Appellant makes similar
arguments regarding the sequence of representative claim 8, since the user in
Win is said to request access to a resource after authentication. App. Br. 21-
22; Reply Br. 4. The issues before us, then, are as follows:

ISSUES
Under § 102, has the Examiner erred by finding that Win:
(1)(a) receives a request for a client system to access a resource, and
(b) sends to the client system information and an instruction for the client
system to send the information to a login server as recited in claim 2?
Appeal 2009-006670
Application 10/477,764

8
(2)(a) receives a request for a client system to access a resource; (b)
authenticates that the client system has permission to access the resource;
and (c) sends an authentication message and instruction to send the
authentication message to the resource recited in claim 8?

ADDITIONAL FINDINGS OF FACT
5. Win’s information access system 2 enables, secure and selective
access to network resources based on the user’s role in an organization (e.g.,
employee, customer, distributor, supplier). The system comprises access
server 106, protected servers 104, 112, and registry server 108. Users can
access the system by logging in via a login page URL using a web browser
100. If login is successful, the system presents the user with a personalized
menu (e.g., an HTML page) displaying only the resources that the user can
access. The user then selects a desired resource to access. Win, Abstract;
col. 1, ll. 5-10; col. 4, l. 39 – col. 6, l. 24; Fig. 1.
6. Access server 106 stores a (1) login page, and (2) authentication
client module that authenticates a user by verifying the user’s name and
password stored in registry server 108. If the name and password are
correct, then the authentication client module (1) reads the user’s roles from
the registry server, and (2) encrypts and sends this information in a cookie to
the user’s browser. Win, col. 6, ll. 27-33, 48-55; Fig. 1.
7. Cookies received from a web server in a specific domain are
returned to web servers in that same domain during open URL requests. A
cookie returned by the authentication client module is required to access
protected resources. Win, col. 6, ll. 59-61.
Appeal 2009-006670
Application 10/477,764

9
8. Once a user is authenticated, the access server’s access menu
module returns a personalized menu of accessible resources. When a user
selects a resource, the browser sends an open URL request and cookie to a
protected web server. The cookie’s information is then decrypted and used
to (1) verify that the user is authorized to access the resource, and (2) return
information customized for that user. Win, col. 6, l. 62 – col. 7, l. 5.
9. For URLs involving protected resources 208 on protected server
104, the server checks whether the user is authenticated (i.e., if (1) the
request contains a decryptable “user cookie,” and (2) the request’s IP
address matches that in the cookie). If the conditions are unsatisfied, then
the protected server’s runtime module returns a redirection to the login URL
which, in turn, is sent to the user’s browser 100 via HTTP server 202. Win,
col. 8, ll. 31-44; Fig. 3B.
10. Protected server 112 (1) is coupled to registry server 108; (2)
manages users, resources, and roles; and (3) customizes the format or
content of screen displays presented to browser 100 or enforce password
selection rules. Win, col. 6, ll. 33-44; Fig. 1.
11. We adopt the Examiner’s factual findings regarding Win’s
disclosure pertaining to Figures 5B and 5C (Ans. 11-12).

ANALYSIS
Claims 2-7
Based on the record before us, we find no error in the Examiner’s
anticipation rejection of claim 2 which calls for (1) receiving a request for a
client system to access a resource, and (2) sending to the client system (a)
Appeal 2009-006670
Application 10/477,764

10
information, and (b) an instruction for the client system to send the
information to a login server.
We note at the outset that the “information” and “instruction” recited
in limitations (a) and (b) above merely pertain to data content and constitutes
non-functional descriptive material since it does not further limit the claimed
invention functionally. Such non-functional descriptive material does not
patentably distinguish over prior art that otherwise renders the claims
unpatentable.3
Nevertheless, even if this data content was functional (which it is not),
we still find no error in the Examiner’s reliance on Win for sending the
recited information and instruction to the client. A key aspect of Win’s
authentication procedure for users to access protected resources involves
using information contained in cookies. FF 6-9. Upon verifying the user’s
name and password, the access server sends encrypted information in a
cookie to the user’s browser. FF 6. Notably, when a user selects a resource,
the browser sends a URL request and cookie to a protected web server which
then uses the information contained in the cookie to verify whether the user
is authorized to access the resource. FF 7-9. If not, the user’s browser is
then redirected to a login URL. FF 9.
The clear import of this discussion is that the client is sent not only
information contained in the cookie, but also effectively an “instruction” to
send this information to a “login server” for authentication. We reach this

3 See In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir. 2004); see also Ex parte
Nehls, 88 USPQ2d 1883, 1887-89 (BPAI 2008) (precedential) (discussing
cases pertaining to non-functional descriptive material).
Appeal 2009-006670
Application 10/477,764

11
conclusion since the structure and format of the cookie itself would, at least
in part, instruct the browser to send the cookie and its associated information
to the appropriate server in connection with resource requests. See FF 6-9.
Although the cookie is created after the login routine in Win, nothing
in the claim precludes Win’s sending of this cookie-based information to at
least a protected server—a server that can be considered a “login server”
given the scope and breadth of the limitation. We reach this conclusion
noting the protected server’s user verification and login URL redirection
functions using received cookie information, as well as the server’s
functions associated with login-based information and processes. See FF 9-
10.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 2, and claims 3-7 not separately argued.

Claims 8-13
We also sustain the Examiner’s rejection of representative claim 8 for
reasons similar to those noted previously. Also, we see no error in the
Examiner’s position based on Win’s user authentication and subsequent
sending of cookies to the user’s browser 528 and 530 which, as the
Examiner indicates, correspond to the recited “authentication message” and
“instruction,” respectively. Ans. 11-12; FF 11. Although we find that these
limitations constitute non-functional descriptive material for similar reasons
as noted above in connection with claim 2, we nonetheless find nothing in
claim 8 that precludes the Examiner’s interpretation, particularly in view of
the format and structure of the cookies themselves. In this regard, not only
would the cookies indicate authentication since the user must be
Appeal 2009-006670
Application 10/477,764

12
authenticated to receive the cookies, but the cookies would also effectively
instruct the browser to send the cookie and its associated information to the
appropriate server in connection with resource requests as noted previously.
See FF 11.
Nor are we persuaded of error in the Examiner’s position that at least
the access server’s receiving the user’s request to open a login URL in Win’s
Figure 5B constitutes receiving a request to access a network-based resource
as claimed. See id. Nothing in claim 8 precludes this key prerequisite
request that facilitates authentication, and ultimately accessing requested
resources. Appellants’ arguments to the contrary (App. Br. 22; Reply Br. 3-
4) are not commensurate with scope of the claim.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 8, and claims 9-13 not separately argued.

Claims 16-27
We also sustain the Examiner’s rejection of representative claim 16
essentially for the reasons previously indicated. As noted previously, the
structure and format of the cookie itself would, at least in part, instruct the
browser to send the cookie and its associated information to the appropriate
server in connection with resource requests. See FF 6-9. Moreover, the
browser itself would “execute” this instruction by sending the cookie.
Appellants’ arguments (App. Br. 25-26; Reply Br. 4-5) are simply not
commensurate with the scope of the claim.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 16, and claims 17-21 not separately argued. We reach a
Appeal 2009-006670
Application 10/477,764

13
similar conclusion regarding representative claim 22 which recites
commensurate limitations, and claims 23-27 not separately argued.

CONCLUSION
The Examiner did not err in rejecting claims 1-13 and 16-27 under
§ 102.

ORDER
The Examiner’s decision rejecting claims 1-13 and 16-27 is affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED

pgc

Paul D Greeley Esq
OHLANDT, GREELEY, RUGGIERO & PERLE LLP
One Landmark Square
10th Floor
Stamford, CT 06901-2682