Ex Parte Schofield

Board of Patent Appeals and Interferences

Nov 22, 2011

11260062 (B.P.A.I. Nov. 22, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
11/260,062 10/27/2005 Andrew John Schofield GB920040074US1 6977
58139 7590 11/23/2011
IBM CORP. (WSM)
c/o WINSTEAD P.C.
P.O. BOX 50784
DALLAS, TX 75201
EXAMINER
SOMERS, MARC S
ART UNIT PAPER NUMBER
2159
MAIL DATE DELIVERY MODE
11/23/2011 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte ANDREW JOHN SCHOFIELD
____________

Appeal 2009-008730
Application 11/260,062
Technology Center 2100
____________

Before LANCE LEONARD BARRY, JAY P. LUCAS, and JOHN A.
JEFFERY, Administrative Patent Judges.

BARRY, Administrative Patent Judge.

DECISION ON APPEAL

STATEMENT OF THE CASE
The Patent Examiner rejected claims 1-10. The Appellant appeals
therefrom under 35 U.S.C. § 134(a). We have jurisdiction under 35 U.S.C.
§ 6(b).

Appeal 2009-008730
Application 11/260,062

2
INVENTION AND ILLUSTRATIVE CLAIMS
The Appellant describes the invention at issue on appeal as follows.
"[W]riting to a persistent store can be expensive. The invention . . .
reduc[es] the number of operations performed by a persistence manager
against a persistent store and consequently goes some way to alleviating this
cost." (Spec. ¶0007.) The following claims more specifically describe the
invention on appeal:
1. A method for reducing the number of operations
performed by a persistence manager against a persistent store of
data items, the method comprising:
receiving a plurality of requests from an application;
mapping each request into a transaction for performance
against the persistent store, each transaction comprising at least
one operation;
accumulating a plurality of transactions; and
preprocessing the plurality of transactions to reduce the
number of operations for performance against the persistent
store.

2. The method of claim 1, wherein preprocessing the
plurality of transactions comprises:
maintaining a list of dispatch units, each dispatch unit
containing information about each transaction, including state
information; and
using the list of dispatch units to determine which
transaction state changes can be omitted.

REJECTIONS
Claims 1-5 and 10 stand rejected under 35 U.S.C. § 102(b) as being
anticipated by U.S. Patent Application Pub. No. 2004/0039742 A1
("Barsness").
Appeal 2009-008730
Application 11/260,062

3
Claims 8 and 9 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Barsness.
Claims 6 and 7 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Barsness and Azzedine Boukerche et. al. "T3C: A
Temporary Correct Concurrency Control Algorithm for Distributed
Databases." Parallel Simulations and Distributed Systems (PARADISE)
Research Lab, Department of Computer Science, University of North Texas,
United States, 2000 ("Boukerche").

DISCUSSION
Based on the Appellant's arguments and the dependencies of the
claims, we will decide the appeal of claim 1 individually and the appeal of
claims 2-10 on the basis of claim 2. Therefore, the issues before us follow.
Did the Examiner err in finding that Barsness maps each of a plurality
of requests into a transaction for performance against a persistent store, as
required by independent claim 1?
Did the Examiner err in finding that Barsness maintains a list of
dispatch units, each dispatch unit containing information about each
transaction including state information, as required by dependent claim 2?
We address the issues seriatim.

CLAIM 1
"Both anticipation under § 102 and obviousness under § 103 are two-
step inquiries. The first step in both analyses is a proper construction of the
claims. . . . The second step in the analyses requires a comparison of the
Appeal 2009-008730
Application 11/260,062

4
properly construed claim to the prior art." Medichem, S.A. v. Rolabo, S.L.,
353 F.3d 928, 933 (Fed.Cir. 2003) (internal citations omitted).
Here, we agree with the Examiner's finding that "the Appellant
defined 'mapping' to refer to converting." (Ans. 12.) Specifically, the
Appellant admitted that "[m]apping as used by Appellants may refer to
converting." (Appeal Br. 4.)
"Having construed the claim limitations at issue, we now compare the
claim[ ] to the prior art to determine if the prior art anticipates th[e]
claim[ ]." In re Cruciferous Sprout Litig., 301 F.3d 1343, 1349 (Fed. Cir.
2002). [A]nticipation is a question of fact." In re Hyatt, 211 F.3d 1367,
1371-72, 54 USPQ2d 1664, 1667 (citing Bischoff v. Wethered, 76 U.S. (9
Wall.) 812, 814-15 (1869); In re Schreiber, 128 F.3d 1473, 1477, 44
USPQ2d 1429, 1431 (Fed. Cir. 1997)). "It is axiomatic that anticipation of a
claim under § 102 can be found only if the prior art reference discloses every
element of the claim . . . ." In re King, 801 F.2d 1324, 1326 (Fed. Cir. 1986)
(citing Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730
F.2d 1452, 1457 (Fed. Cir. 1984)).
Here, we find that Barsness generally describes its invention as
follows.
An application on a front-end server may access a database
located on a back-end server via [a] database-enabled
messaging [i.e., DBE] facility. In general, the database-enabled
messaging facility receives a message containing a database
request from the front-end server, parses the message to extract
the database request, submits the database request to the
database, receives results from the database request and sends a
message containing results from the database request to the
front-end server. For some embodiments, the messaging
facility may optimize-accessing the database by changing
Appeal 2009-008730
Application 11/260,062

5
database requests-prior to submitting them to the database. For
example, the messaging facility may reorder database requests,
delete redundant database requests, or combine database
requests to minimize a total number of database accesses.
(Abstract (emphasis added).)
We also agree with the Examiner's finding that because the
reference's "database request message is a request and parsing maps one
thing into another thing, it is clear that mapping each request into a
transaction against the persistence store is taught." (Ans. 12.) Bareness
describes the details of this operation as follows
[T]he DBE messaging facility 224 parses the database request
message to extract the database request. For example, if the
database request was embedded in the message as simple text,
the database interface service 260 may simply treat the
application data portion of the message as a database request
(i.e., extract the text). Alternatively, if the database request was
encoded or compressed prior to being embedded in the
message, the database interface service 260 may decode or
decompress the database request.
(¶ 0045.) More specifically, we find that the extraction of the text, with or
without the decoding and decompressing thereof, converts the database
request message into a database request.
We also agree with the Examiner's alternative finding that "[a]s
discussed at the bottom of paragraphs [0043] and [0045] of Barsness, the
[reference's] database request message may contain parameters and the
actual database requests/ transactions . . . have to be constructed/converted
from the database request message." (Ans. 12.) The Appellant argues that
"there is no language in paragraphs [0043 and 0045] that suggests mapping."
(Reply Br. 4.)
Appeal 2009-008730
Application 11/260,062

6
The reference supports the Examiner's finding, however, by
disclosing that "the database request message may contain parameters for
constructing the database request, rather than the entire request" (¶ 0043),
and "if the database request message contained parameters for constructing
the database request, the DBE messaging facility may extract the parameters
and construct the database request from the extracted parameters." (¶ 0045.)
More specifically, we find that the construction of the database request from
the extracted parameters would at least have suggested mapping. Therefore,
we conclude that the Examiner did not err in finding Barsness maps each of
a plurality of requests into a transaction for performance against a persistent
store, as required by independent claim 1.

CLAIM 2
Claim 2 recites in pertinent part the following limitations:
"maintaining a list of dispatch units, each dispatch unit containing
information about each transaction, including state information . . . ."
The Examiner finds that "Barsness in paragraph [0057] states that the
system uses two-phase commit transactions, similar to the two-phase
commit protocol described in the Appellant's [S]pecification at
paragraph [0020]." (Ans. 17.)
[U]nless a reference discloses within the four corners of the
document not only all of the limitations claimed but also all of
the limitations arranged or combined in the same way as recited
in the claim, it cannot be said to prove prior invention of the
thing claimed and, thus, cannot anticipate under 35 U.S.C.
§ 102.
Net MoneyIn, Inc. v. VeriSign, Inc., 545 F.3d 1359, 1371 (Fed. Cir.
2008.)
Appeal 2009-008730
Application 11/260,062

7
Here, we agree with the Appellant that "[t]here is no language in
[Paragraph 0057] that discloses that the database request (Examiner equates
the database request of Barsness with the claimed dispatch unit) contains
information about each transaction, including state information." (Reply Br.
5.) To the contrary, we find that the reference uses separate data to
accomplish its two-phase transaction as follows.
During a first phase, the front-end application may ask the DBE
messaging facilities if they are ready to commit updates. If all
DBE messaging facilities respond positively, they may be asked
to commit their updates in the second phase. Otherwise, the
DBE messaging facilities may be asked to roll back their
updates in the second phase.
(¶ 0057.) We also agree with the Appellant that merely "[p]ermitting
updates to be committed or rolled back is not a dispatch unit containing
information about a transaction. Neither is permitting updates to be
committed or rolled back a dispatch unit containing information about a
transaction, including state information." (Reply Br. 5.)
The Examiner does not allege, let alone show, that the addition of
Boukerche cures the aforementioned deficiency of Barsness. Therefore, we
conclude that the Examiner erred in finding that Barsness maintains a list of
dispatch units, each dispatch unit containing information about each
transaction including state information, as required by dependent claim 2

DECISION
We affirm the rejection of claim 1.
In contrast, we reverse the rejections of claim 2 and those of claims 3-
10, which depend therefrom.
Appeal 2009-008730
Application 11/260,062

8
No time for taking any action connected with this appeal may be
extended under 37 C.F.R. § 1.136(a)(1). See 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED-IN-PART

tkl