Ex Parte Markovich

Patent Trial and Appeal Board

Apr 2, 2015

12285739 (P.T.A.B. Apr. 2, 2015)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________

Ex parte SLAVIK MARKOVICH
____________________

Appeal 2012-010280
Application 12/285,739
Technology Center 2400
____________________

Before BRUCE R. WINSOR, MATTHEW R. CLEMENTS, and
JOHN F. HORVATH, Administrative Patent Judges.

HORVATH, Administrative Patent Judge.

DECISION ON APPEAL

STATEMENT OF THE CASE
Appellant seeks our review, under 35 U.S.C. § 134(a), of the
Examiner’s rejection of claims 1–20. We have jurisdiction under 35 U.S.C.
§ 6(b).
We REVERSE and enter NEW GROUNDS OF REJECTION
pursuant to our authority under 37 C.F.R. § 41.50(b) (2011).

Appeal 2012-010280
Application 12/285,739

2
SUMMARY OF THE INVENTION
The invention is directed to a method for user identification.
Claim 1, reproduced below, is illustrative of the claimed subject
matter:
1. A method for user identification, the method comprising
relaying an identifier of a user of an application server to
a database associated with the application server,
wherein the relaying is performed via a transaction
request from the application server to the database, and
wherein the transaction request includes a request to
perform at least one of retrieving data from the database,
storing data in the database and altering data in the database.

REFERENCES
Frolund et al. US 6,442,552 B1 Aug. 27, 2002
Wong US 6,986,060 B1 Jan. 10, 2006
Iyer Venkatasubramaniam et al., Oracle Database JDBC Developer’s
Guide and Reference 10g Release 2, Chapter 30 (Oracle 2007).

REJECTIONS
Claims 1–20 were provisionally rejected on the ground of non-
statutory obviousness-type double patenting over claims 1–18 of Application
No. 12/285,747 (the ’747 Application), now abandoned. Ans. 4; Non Final
Action 3; ’747 Application Notice of Abandonment (mailed Oct. 12, 2012).
Claims 1–4, 6, 8–11, 13, and 15–18 stand rejected under 35 U.S.C
§103(a) as unpatentable over Wong and Frolund. Ans. 5–8.
Claims 5, 7, 12, 14, 19, and 20 stand rejected under 35 U.S.C §103(a)
as unpatentable over Wong , Frolund, and Venkatasubramaniam. Ans. 8–9.
Appeal 2012-010280
Application 12/285,739

3
ISSUES AND ANALYSIS
I. Provisional Double Patenting Rejection.

Claims 1–20 were provisionally rejected over claims 1–18 of the ’747
Application on the grounds of non-statutory obviousness-type double
patenting. This rejection is rendered moot by the abandonment of the ’747
Application and is, therefore, no longer before us. See ’747 Application
Notice of Abandonment.

II. Whether Wong teaches or suggests relaying or attaching a user
identifier in a transaction request that retrieves, stores, or
alters data in a database as recited in claims 1, 8, and 15.

The Examiner finds Wong teaches or suggests relaying and attaching
a user identifier to a database in a transaction request by teaching forwarding
a username to a database server in a request to start a database session and
sending a query to the database server. Ans. 5, 9–11 (citing Wong 6:13–26).
Appellant argues these disclosures represent separate transactions: a first
transaction in which the username is exchanged to establish a database
session, and a second transaction to submit a query to the database server via
the database session. Br. 7. Moreover, Appellant argues Wong’s
description of sending a query to the database server, identified by the
Examiner as sending a transaction request, fails to teach or suggest the query
includes a user identifier. Id. at 9.
On the record before us, we agree with Appellant. The Examiner
finds Wong teaches relaying the user identifier in the session request to the
database server, but makes no findings that the session request is a
Appeal 2012-010280
Application 12/285,739

4
transaction that retrieves, stores, or alters information in a database. See
Ans. 5–6, 9–11. Likewise, the Examiner finds Wong teaches sending a
query to the database server that alters data in a database, but makes no
findings that the query includes a user identifier. Id.
Consequently, we reverse the rejection of claims 1–20 for this reason.
However, because we find Wong’s request to establish a database session
includes both a user identifier and a request to store the user identifier and a
database session ID in a database, we reject claims 1, 8, and 15 on new
grounds as explained infra.
NEW GROUNDS OF REJECTION
Claims 1, 8, and 15 are rejected on new grounds under 35 U.S.C.
§ 103(a) as unpatentable over Wong.
We construe the term “database,” as recited in claims 1, 8, and 15, to
have its broadest reasonable interpretation in view of the Specification. In re
Morris, 127 F.3d 1048, 1054 (Fed. Cir. 1997). The Specification indicates a
“database . . . is a computerized tool for storing digital data in an orderly
manner.” Spec. 1:12–13. Consequently, we construe a database to include a
computer storage area for storing digital data in an orderly manner, such as
global application pool 122 shown in Figure 1 of Wong.
Wong teaches storing a security context for user 102 in application
pool 122 on database server 120. Wong 4:51–57, 5:9–12, Figs. 1, 2. The
security context consists of security attributes for the user, such as the user’s
department, responsibilities, and access privileges. Id. at 2:40–46.
The application pool stores the security context data in an orderly manner,
such that it can be indexed and retrieved based on the user’s username or the
Appeal 2012-010280
Application 12/285,739

5
session ID of a database session. Id. at 5:12–15. Consequently, the
application pool is a database for storing user security attributes.
Wong teaches user 102 (e.g., Scott) can log onto analysis tool 115 on
application server 113. Wong 5:5–8, 6:6–16, 6:22–23, Figs. 1, 4. The
analysis tool creates database session 132 with database server 120 by
forwarding the username and password of user 102 to database server 120,
1

and associating the username with the database session. Id. at 6:16–22. In
subsequent transactions, Wong teaches retrieving the username and the
security context for user 102 from application pool 122 on database server
120 based on database session 132. Id. at 6:24–34. Consequently, Wong’s
teaching to associate the username with database session 132 teaches or
suggests storing that information in application pool 122. See, e.g., Wong
4:52–57 (teaching “assigning a session ID to user 102, such as 12345, and
then using the function call SET_CONTEXT(‘HR’, ‘RESP’, ‘13’,
‘APPSMGR’, ‘12345’)[] to record a context for user 102 in global
application pool 122 on database server 120.”). Therefore, Wong’s request
to create database session 132, which includes the username of user 102,
includes a request to store the username and session ID for database session
132 in global application pool 122, and is therefore a request to store data in
a database (i.e., a transaction request).

1
We acknowledge Appellant’s argument that the username forwarded by the
analysis tool is that of the application server rather than of a user of the
application server, and find it unpersuasive. See App. Br. 8. Wong teaches
the username is that of user 102 named ‘SCOTT,’ who logs onto analysis
tool 115 on application server 113. See Wong 6:16–23, Figs. 1, 4.
Appeal 2012-010280
Application 12/285,739

6
For the reasons explained supra, we find Wong teaches or suggests
the limitations of claim 1, namely, relaying an identifier of a user of an
application server to a database associated with the application server
(forwarding the username of user 102 of application server 113 to database
server 120), wherein the relaying is performed via a transaction request from
the application server to the database (relaying the username in a request to
establish database session 132), and wherein the transaction request includes
a request to perform at least one of retrieving data from the database, storing
data in the database and altering data in the database (the request to establish
database session 132 includes a request to associate the username with a
session ID for database session 132 by storing the username and session ID
in application pool 122). Thus, the invention of claim 1 is at most a
predictable variation that would have been obvious to a person of ordinary
skill in the art using no more than the inferences and creative steps such a
person would employ. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417-18
(2007).
Claim 8 differs from claim 1 in that it recites attaching the identifier
of the user of the application server to the transaction request. Claims
App’x. As explained supra, Wong discloses establishing database session
132 with database server 120 by attaching a username (identifier) to the
request to establish the database session. See, e.g., Wong 4:52–60, (teaching
application 114 assigns “a session ID to user 102, such as 12345, and then
us[es] the function call SET_CONTEXT(‘HR’, ‘RESP’, ‘13’, ‘APPSMGR’,
‘12345’)[] to record a context for user 102 in global application pool 122 on
database server 120,” where ‘APPSMGR’ is the name of a database user.).
Appeal 2012-010280
Application 12/285,739

7
Claim 15 differs from claim 1 in that the identifier relayed to the
database is an identifier of a rich client user rather than a user of an
application server. Claims App’x. We construe the term “rich client” to
have its broadest reasonable interpretation in view of the Specification. In re
Morris, 127 F.3d at 1054. The Specification indicates the term ‘rich client’
refers to a software application, such as a Java client, running on a computer
and used to access an application server, or a computer that functions as
such a software application. Spec. 5:5–10. Consequently, we construe the
term rich client to include a computer used to access an application server,
such as computer 104 shown in Figure 1 of Wong.
Wong teaches or suggests user 102 accesses application server 113 via
computer client 104. Wong 3:26–30, 3:49–51, Fig. 1. Consequently, the
username of user 102 is an identifier of both a rich client user (i.e., a user of
client computer 104) as recited in claim 15, and of a user of an application
server (i.e., a user of application server 113). Id.
In rejecting claims 1, 8, and 15, we note that we are primarily a
reviewing body, rather than a place of initial examination. We therefore
leave it to the Examiner to determine whether those claims that depend from
claims 1, 8, and 15, respectively, should be rejected on similar grounds to
those set forth herein or in combination with additional prior art. The fact
that we did not enter new grounds of rejection for the dependent claims
should not be construed to mean that we consider the dependent claims to be
patentable over the prior art of record.
Appeal 2012-010280
Application 12/285,739

8
DECISION
For the reasons indicated above, the Examiner’s rejection of claims 1–
20 is reversed.
Pursuant to our authority under 37 C.F.R. § 41.50(b), we enter new
grounds of rejection, rejecting claims 1, 8, and 15 under 35 U.S.C. § 103(a)
as unpatentable over Wong.
This decision contains new grounds of rejection pursuant to 37 C.F.R.
§ 41.50(b). Section 41.50(b) provides that “[a] new ground of rejection
pursuant to this paragraph shall not be considered final for judicial review.”
Rather, WITHIN TWO MONTHS FROM THE DATE OF THE
DECISION, Appellants must exercise one of the following two options with
respect to the new ground of rejection to avoid termination of the appeal as
to the newly rejected claims:
(1) Reopen prosecution. Submit an appropriate amendment of the
claims so rejected or new evidence relating to the claims so
rejected, or both, and have the matter reconsidered by the
examiner, in which event the proceeding will be remanded to the
examiner. . . .

(2) Request rehearing. Request that the proceeding be reheard under
§ 41.52 by the Board upon the same record. . . .

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).

REVERSED
37 C.F.R. § 41.50(b)
dm