Ex Parte Foster et al

Board of Patent Appeals and Interferences

May 3, 2012

10286063 (B.P.A.I. May. 3, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE BOARD OF PATENT APPEALS 4
AND INTERFERENCES 5
___________ 6
7
Ex parte WARD SCOTT FOSTER, 8
CHARLES J. GAZDIK, 9
and SHELL STERLING SIMPSON 10
___________ 11
12
Appeal 2010-010202 13
Application 10/286,063 14
Technology Center 3600 15
___________ 16
17
18
Before HUBERT C. LORIN, ANTON W. FETTING, and 19
JOSEPH A. FISCHETTI, Administrative Patent Judges. 20
FETTING, Administrative Patent Judge. 21
DECISION ON APPEAL 22
23
Appeal 2010-010202
Application 10/286,063

2

STATEMENT OF THE CASE1 1
Ward Scott Foster, Charles J. Gazdik, and Shell Sterling Simpson 2
(Appellants) seek review under 35 U.S.C. § 134 (2002) of a final rejection of 3
claims 1-15, 17-30 and 32-43, the only claims pending in the application on 4
appeal. We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b) 5
(2002). 6
The Appellants invented a way for securely authenticating a user 7
attempting to access a network resource (Specification ¶ 0001). 8
An understanding of the invention can be derived from a reading of 9
exemplary claim 1, which is reproduced below [bracketed matter and some 10
paragraphing added]. 11
1. In a computer network, a user authentication method 12
comprising: 13
[1] receiving a request 14
from a client of the computer network 15
to access a resource 16
located on a first uniform resource locator (URL) 17
website root domain; 18
[2] acquiring 19
access data for 20
a decentralized authentication service 21
and 22
return access data 23

1 Our decision will make reference to the Appellants’ Appeal Brief (“App.
Br.,” filed October 26, 2009) and Reply Brief (“Reply Br.,” filed April 30,
2010), and the Examiner’s Answer (“Ans.,” mailed March 4, 2010).
Appeal 2010-010202
Application 10/286,063

3

for accessing the resource of the computer 1
network, 2
wherein the access data includes 3
a second URL website root domain that is 4
autonomous 5
and 6
different from the first URL website root 7
domain; 8
and 9
[3] redirecting 10
the client of the computer network 11
through a network transaction 12
to the second URL website domain 13
to request authentication, 14
the redirection including 15
the access data for the decentralized authentication 16
service 17
and 18
the return access data for the resource. 19
The Examiner relies upon the following prior art: 20
Wood US 6,668,322 B1 Dec. 23, 2003
Dujari US 7,191,467 B1 Mar. 13, 2007
Claims 1-15 stand rejected under 35 U.S.C. § 101 as directed to non-21
statutory subject matter. 22
Claims 32-43 stand rejected under 35 U.S.C. § 112, second paragraph, as 23
failing to particularly point out and distinctly claim the invention. 24
Appeal 2010-010202
Application 10/286,063

4

Claims 1-15, 17-30, and 32-43 stand rejected under 35 U.S.C. § 103(a) 1
as unpatentable over Wood and Dujari. 2
ISSUES 3
The issue of statutory subject matter turns primarily on whether the 4
claims describe controlling computer operation. The issue of indefiniteness 5
turns primarily on whether describing a structure in terms of its function is 6
indefinite. The issues of obviousness turn primarily on whether the art 7
describes or show to be predictable autonomous servers and a different URL 8
root domain. 9
FACTS PERTINENT TO THE ISSUES 10
The following enumerated Findings of Fact (FF) are believed to be 11
supported by a preponderance of the evidence. 12
Facts Related to Appellants’ Disclosure 13
01. The originally filed disclosure does not define, nor even recite, the 14
phrase “root domain.” This phrase was added to the claims in an 15
amendment filed August 5, 2008. 16
02. One of ordinary skill knew that the root domain of a website is 17
generally the last two textual tokens separated by a single period 18
character in the website’s URL. As an example, the USPTO web 19
site has “uspto.gov” as its root domain. 20
Facts Related to the Prior Art 21
Wood 22
03. Wood is directed to a security architecture in which a single sign-23
on is provided. Session credentials are used to maintain continuity 24
Appeal 2010-010202
Application 10/286,063

5

of a persistent session across multiple accesses to one or more 1
information resources, and in some embodiments, across 2
credential level changes. Session credentials are secured, e.g., as a 3
cryptographically secured session token, such that they may be 4
inspected by a wide variety of entities or applications to verify an 5
authenticated trust level, yet may not be prepared or altered except 6
by a trusted authentication service. Wood associates trust level 7
requirements with information resources. Authentication schemes 8
(e.g., those based on passwords, certificates, biometric techniques, 9
smart cards, etc.) are associated with trust levels, and with 10
environmental parameters. Once login credentials have been 11
obtained for an entity and have been authenticated to a given trust 12
level, session credentials are issued and access is granted to 13
information resources for which the trust level is sufficient. By 14
using the session credentials access is granted without the need for 15
further login credentials and authentication. Session credentials 16
evidencing an insufficient trust level may be remedied by a 17
session continuity preserving upgrade of login credential. Wood 18
2:27-55. 19
04. Authorization of the application security framework for access to 20
components of the central security portion is checked by query to 21
central authorization service. A central authentication service, in 22
turn, interacts with central principal registry to establish the 23
identity and group membership of user and with central session 24
registry to create a persistent session for subsequent accesses by 25
user. Particulars of the request are logged to central audit service 26
Appeal 2010-010202
Application 10/286,063

6

308 and, if authentication was successful, session credentials are 1
returned to application security framework. Signed session 2
credentials are presented to application authorization service 313 3
together with an identifier for the requested resource and 4
optionally with an identifier for a particular function or facility of 5
the requested resource. In response, application authorization 6
service 313 checks the authorization of the principal (e.g., of user 7
301) associated with the session credentials to access the 8
requested resource. Application authorization service 313 9
interacts with application resource registry 314 to identify trust 10
level requirements for the requested resource (and in some 11
configurations, for a particular function or facility of the requested 12
resource) and determines the sufficiency of a current trust level 13
evidenced by the session credential. Note that trust level is 14
assessed by inspection of the session credential and without 15
interaction with an authentication service. In some configurations 16
(e.g., as illustrated in FIG. 3), group membership is also evaluated 17
as part of the authorization check. Once login credentials are 18
obtained, they are passed to central security framework for 19
authentication by central authentication service so that session 20
credentials can be obtained, the requested access can be 21
authorized, and the order processing initiated. Signed session 22
credentials, typically embodied as a cryptographically secured 23
session token that may be stored as a cookie, are passed back to 24
browser with results of the requested access. In this way, 25
subsequent access requests are identified as part of a session and 26
Appeal 2010-010202
Application 10/286,063

7

authorization may be quickly confirmed without unnecessary re-1
authentication. Wood 19:32 – 20:32. 2
Dujari 3
05. Dujari is directed to participating web servers that automatically 4
use a client's local system-based authentication mechanism for 5
systems with a browser finite state machine (FSM) code that is 6
capable of recognizing a response requesting local authentication. 7
For (legacy) browser FSM code that is not capable of handling the 8
new type of authentication, the existing redirect/page-based 9
authentication mechanism is automatically used. This is possible 10
because the response's authentication request is transparent to 11
legacy browser FSM code, such that the browser FSM code is not 12
broken by the new type of response, yet is recognized by updated 13
browser FSM code. At the same time, servers that are not (yet) 14
configured to provide the new local system-based authentication 15
requests will be able to continue to use the existing redirect/page-16
based authentication mechanism, with both updated and legacy 17
browser FSM code. Dujari 2:13-30. 18
06. A network of computers is arranged for use with a third party 19
authentication service (e.g., Microsoft.RTM. .NET Passport, or 20
simply Passport), including a participating server, a client 21
computer, and a third party login server. A participating server is 22
an entity (e.g., organization or person) having a site account that 23
makes use of the third party authentication service. The login 24
server refers to a server of the trusted third party authentication 25
Appeal 2010-010202
Application 10/286,063

8

service or the hierarchy of services that stores and administers 1
member and site accounts, (e.g., Passport). Dujari 6:46-61. 2
07. Dujari FIG. 3 shows the general flow of communication in a 3
network 300 between a client 306, participating server 604, third 4
party domain authority nexus server and third party login server 5
308. In FIG. 3, a domain authority generally defines an 6
organization that is part of a third party authentication service, and 7
administers a given subset of the member accounts and/or a given 8
subset of the site accounts. Each domain authority has a login 9
server that represents the domain authority that in the SSI 10
protocol, e.g., login.Passport.com, and also a nexus server that 11
provides information describing the topography of the third party 12
authentication service's network, including the distribution of the 13
member (and site) accounts among several domain authorities, the 14
URLs of particular resources in each domain authority, and so 15
forth. Dujari 8:17-35. 16
08. When the client requests a resource on a server, e.g., the GET 17
request, the program manager in the server determines whether the 18
request requires third party authentication. If so, the server checks 19
the request for the presence of tickets. If a valid ticket is sent with 20
the request, the server responds with the requested resource. If a 21
valid ticket was not sent by the client, the server responds with a 22
302 status code (e.g., the arrow labeled two (2) in FIG. 3). Dujari 23
8:36-45. 24
Appeal 2010-010202
Application 10/286,063

9

09. For example, the response may include the challenge header, 1
"WWW-Authenticate: Passport 1.4" (or later version). As 2
described above, clients that are not updated follow the redirection 3
to the third party authentication service login server. Updated 4
clients recognize the challenge header information, and typically 5
contact the domain authority's nexus server 312 to determine the 6
login server. The client then communicates with the third party 7
authentication service's login server, which handles requests for 8
tickets for any resource in the domain authority. Before a request 9
can be authenticated by the third party authentication service, the 10
client contacts the login server to obtain the appropriate tickets. 11
Dujari 8:46-62. 12
10. When a client requests tickets from the login server, the login 13
server typically responds with an HTTP 401 status code to 14
indicate that user credentials need to be provided. Upon the 15
provision of these credentials, the login server responds with the 16
tickets required to access the server containing the originally 17
requested resource. The login server can also redirect the client to 18
another server that can provide the requested resource. Dujari 19
8:63 – 9:5. 20
11. When the client has the tickets corresponding to a given server, 21
those tickets are included with future requests to that server, such 22
as in the redirected GET request represented in FIG. 3 by the 23
arrow labeled nine (9). If the tickets have not been modified since 24
they were retrieved from the login server, and the tickets are valid 25
for the resource server, the resource server sends a response (e.g., 26
Appeal 2010-010202
Application 10/286,063

10

the arrow labeled ten (10)) that includes both the requested 1
resource and cookies indicating that the user is authenticated for 2
future requests. The additional cookies in the response are 3
intended to speed the authentication process, in that additional 4
requests (in the same session) for resources on servers in the same 5
third party authentication service will include these additional 6
cookies. As a result, credentials do not need to be sent to the login 7
server again until the cookies expire, which may be per session or 8
persisted for multiple sessions. Dujari 9:6-23. 9
ANALYSIS 10
Claims 1-15 rejected under 35 U.S.C. § 101 as directed to non-statutory 11
subject matter. 12
We are persuaded by the Appellants’ argument that independent claim 1 13
recites steps that are tied to a particular device, that is, a computer that can 14
receive requests, acquire access data, and redirect a client. Appeal Br. 9. 15
The Examiner found that: 16
[c]laim 1 discloses a mere nominal recitation of technology and 17
fails to transform the underlying subject matter to a different 18
state, therefore the claimed method is nonstatutory. 19
Ans. 4. This is a conclusionary statement and fails to make findings as 20
to why acquiring access data and redirecting a client are not steps controlling 21
the operation of a computer. 22
Claims 32-43 rejected under 35 U.S.C. § 112, second paragraph, as failing 23
to particularly point out and distinctly claim the invention. 24
Appeal 2010-010202
Application 10/286,063

11

We are persuaded by the Appellants’ argument that the access module of 1
claim 32 is a software module structurally defined by the functions it 2
performs. Appeal Br. 10. Thus the scope of the claims is definite. The 3
Examiner’s findings are more directed to an issue of scope of enablement or 4
written description of a genus, but there is no rejection under such rationales. 5
Claims 1-15, 17-30, and 32-43 rejected under 35 U.S.C. § 103(a) as 6
unpatentable over Wood and Dujari. 7
We are not persuaded by the Appellants’ argument that the art fails to 8
describe or render predictable the rejected claims. Appeal Br. 11-15. The 9
Examiner made factual findings that rebutted each of the Appellants’ 10
arguments, and we adopt those factual findings and analysis as to the 11
obviousness rejections at Answer 5-11 and 13-15 and reach similar legal 12
conclusions. Thus we have only the arguments raised in the Reply Brief 13
remaining. 14
We are not persuaded by the Appellants’ argument that the art fails to 15
describe autonomous servers and a different URL root domain. We 16
appreciate Appellants’ assistance in defining the word autonomous as 17
independent, but find this is not dispositive. Nothing in any network is 18
entirely autonomous, because network traffic into and out of the computer 19
alter the internal state of the machine dynamically. A computer must be 20
divorced from any communication channel to any other computer to be 21
completely autonomous. Thus, the recited attribute of being autonomous is 22
necessarily a matter of degree. As Wood’s servers clearly have their own 23
programming, separate from the programming in other computers on the 24
network, they are autonomous at least to that degree. 25
Appeal 2010-010202
Application 10/286,063

12

As to the different URL website root domain, such a different root 1
domain does not necessarily require a separate machine as Appellants argue, 2
as the root domain is simply part of an identifier that is mapped to a 16 digit 3
number that specifies a machine. Thus, the root domain, being no more than 4
an identifier, is non-functional descriptive material that cannot distinguish 5
the claim over the art. Also, since it is merely an identifier, nothing 6
precludes mapping two root identifiers to the same machine. Anyone who 7
has ever used a URL alias to reduce typing in accessing a web page is 8
familiar with this, at least in concept. More to the point, Wood clearly uses 9
a decentralized authentication service on a machine separate from the 10
machine requesting authentication. Therefore Wood is using separate 11
machines, not the same machine for the different URL’s. Contrary to 12
Appellants’ contention that Wood teaches away from using separate 13
domains, nothing in Wood would preclude this or even suggest it is 14
inadvisable. 15
CONCLUSIONS OF LAW 16
The rejection of claims 1-15 under 35 U.S.C. § 101 as directed to non-17
statutory subject matter is improper. 18
The rejection of claims 32-43 under 35 U.S.C. § 112, second paragraph, 19
as failing to particularly point out and distinctly claim the invention is 20
improper. 21
The rejection of claims 1-15, 17-30, and 32-43 under 35 U.S.C. § 103(a) 22
as unpatentable over Wood and Dujari is proper. 23
DECISION 24
The rejection of claims 1-15, 17-30, and 32-43 is affirmed. 25
Appeal 2010-010202
Application 10/286,063

13

No time period for taking any subsequent action in connection with this 1
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 2
§ 1.136(a)(1)(iv) (2007). 3
4
AFFIRMED 5
6
7
8
MP 9