Ex Parte Deolasee

Board of Patent Appeals and Interferences

Jul 13, 2010

10880383 (B.P.A.I. Jul. 13, 2010)

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.
10/880,383 06/29/2004 Pavan Vijaykumar Deolasee VRTS0830 9767
44743 7590 07/14/2010
RAYMOND R. MOSER JR., ESQ.
MOSER IP LAW GROUP/SYMANTEC CORPORATION
1030 BROAD STREET
SUITE 203
SHREWSBURY, NJ 07702
EXAMINER
CHU, GABRIEL L
ART UNIT PAPER NUMBER
2114
MAIL DATE DELIVERY MODE
07/14/2010 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 PAVAN VIJAYKUMAR DEOLASEE
____________
Appeal 2009-002488
Application 10/880,3831
Technology Center 2100
____________

Before JOHN A. JEFFERY, LEE E. BARRETT, and JAY P. LUCAS,
Administrative Patent Judges.

BARRETT, Administrative Patent Judge.

DECISION ON APPEAL2

1 Filed June 29, 2004, titled "Method and Apparatus for Providing
In-Memory Checkpoint Services Within a Distributed Transaction." The
real party in interest is Symantec Operating Corporation.
2 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-002488
Application 10/880,383

2
This is a decision on appeal under 35 U.S.C. § 134(a) from the final
rejection of claims 1, 3-13, 15-17, and 19. Claims 2, 14, 18, and 20 have
been canceled. We have jurisdiction pursuant to 35 U.S.C. § 6(b).
We affirm.

STATEMENT OF THE CASE
The invention
The invention relates to performing in-memory checkpoint services as
a callable resource within a distributed transaction. As such, in-memory
checkpoint processes can be utilized by an application as the application
would use any resource available to the computer network via a distributed
transaction. See Abstract.

Illustrative claim
Claim 1 is reproduced below for illustration:

1. A method for performing a distributed transaction, comprising:

during a distributed transaction, performing an in-memory
checkpoint process as a resource for an application executing on a
server, the in-memory checkpoint process storing critical memory
information and states of the server at a particular instant in time.

The reference

Raventos US 2002/0194244 A1 Dec. 19, 2002

Appeal 2009-002488
Application 10/880,383

3
The rejection
Claims 1, 3-13, 15-17, and 19 stand rejected under 35 U.S.C. § 102(b)
as being anticipated by Raventos.

DISCUSSION
Claims 1 and 5
Issue 1: Does Raventos teach "performing an in-memory checkpoint
process as a resource for an application executing on a server"?

Appellant argues that Raventos does not teach "performing an in-
memory checkpoint process as a resource for an application executing on a
server" (emphasis added) because in "Raventos, the checkpoint/logging
process is performed on behalf of the resource manager" (Br. 7) and
"performing a checkpoint/logging process on behalf of the resource
manager, as disclosed in Raventos, does not teach or suggest performing an
in-memory checkpoint process as a resource for an application executing on
a server, as claimed by Appellant" (Br. 7-8).
The Examiner finds that the resource manager in Raventos operates
"on behalf" of an application to enable transaction processing through task
logging, relying on paragraph 0061 of Raventos. Ans. 10-11.
We find that Raventos meets the limitation at issue as broadly
claimed. Initially, we conclude that it is not necessary that Raventos show
an "in-memory checkpoint process [resource]" as a discrete separate element
such as resources 410A, 410B, and 410C in Figure 7. If the resource
manager performs an "in-memory checkpoint process" it is considered an
Appeal 2009-002488
Application 10/880,383

4
"in-memory checkpoint process [resource]." There does not seem to be any
dispute that the resource manager performs an "in-memory checkpoint
process" as described at paragraph 0061. The dispute is whether it performs
the process "for an application executing on a server."
It is observed that claim 1 does not recite that the application "calls"
the "in-memory checkpoint process [resource]." Therefore, it is sufficient
that the checkpoint process is performed on behalf of the application.
Raventos describes in connection with Figure 7 that a client requests a
functional service which request is received by interface 401 and an E2A
server 403 provides the resources needed to perform the functional services,
where Resource Manager 405 and Transaction Manager 404 interact to
perform a transaction. ¶ 0054. A "transaction" is a logical unit of work that
either wholly succeeds or has no effect whatsoever. ¶ 0026. We find that
the client is an application executing on a server and the resource manager
and transaction manager act for the application to execute the transaction.
Raventos describes that an XID object 408A is created for each transaction
and a persistent task repository is maintained for the transaction represented
by XID object 408A. ¶ 0055. The resource manager manages transactions
according to the XA protocol. ¶ 0056. If a transaction is successfully
performed, the XID object for this transaction is destroyed, but if the tasks
were not successfully completed the resource manager signals a rollback to
the transaction manager which causes the rest of the steps in the transaction
to be rolled back. ¶ 0057. Since the resource manager is checkpointing the
transaction, it is doing so on behalf of the client application on the server.
Appeal 2009-002488
Application 10/880,383

5
Each object may have a particular state corresponding to the state of its
respective transaction. ¶ 0058. The resource manager maintains a task log
which tracks the status of every task being performed for the various
transactions and "checkpoints may be provided within an object to represent
'Safe' points the resource manager can rollback to versus the rest of the
persistence points." ¶ 0061. Thus, checkpoints are provided in the XID
object by the resource manager for an application transaction to allow the
resource manager to rollback the tasks for a transaction on behalf of the
application if the application transaction is not successful. We find that the
checkpointing is done by the request manager to track the success of
transactions requested by a client application. Therefore, we find that
Raventos teaches "performing an in-memory checkpoint process as a
resource for an application executing on a server."
The Examiner interprets Appellant's argument as stating "that the
'resource manager' is intended to operate in the same memory as a server's
application, hence, 'in-memory' checkpoint." Ans. 10. Appellant disputes
this interpretation and states that the "argument is simply that performing a
checkpoint process for a resource manager, as taught in Raventos, does not
teach or suggest performing an in-memory checkpoint processor [sic] as a
resource for an application executing on a server." Reply Br. 2.
We agree with Appellant that the argument has nothing to with
operating in the same memory. Appellant does not argue the "in-memory"
limitations. The Examiner's statement is harmless error.

Appeal 2009-002488
Application 10/880,383

6
Issue 2: Does Raventos teach "the in-memory checkpoint process
storing critical memory information and states of the server at a
particular instant in time"?

Appellant argues that Raventos does not teach "the in-memory
checkpoint process storing critical memory information and states of the
server at a particular instant in time" because the task log in Raventos stores
status of the various transactions executed by the resource manager, not the
server. "The task log in Raventos does not store any critical information or
states of the server executing the application. There is no teaching or
suggestion in Raventos that the resource manager 405 is aware of any such
critical information or states of the sever [sic]/system executing the
application 401/301." Br. 8.
Raventos describes that an XID object 408A is created for each
transaction and a persistent task repository is maintained for the transaction
represented by XID object 408A. ¶ 0055. Each object may have a particular
state corresponding to the "state" of its respective transaction. ¶ 0058. The
transaction is a transaction on behalf of a client application executing on a
server so we find that the states include the "states of the server at a
particular instant in time." The resource manager maintains a task log which
tracks the status of every task being performed for the various transactions
and "checkpoints may be provided within an object to represent 'Safe' points
the resource manager can rollback to versus the rest of the persistence
points." ¶ 0061. Checkpoints would include "critical memory information
. . . at a particular instant in time" necessary to allow rollback of tasks.
Appeal 2009-002488
Application 10/880,383

7
In summary, we find that Raventos teaches "the in-memory
checkpoint process storing critical memory information and states of the
server at a particular instant in time." Therefore, the rejection claim 1 is
affirmed. Claim 5 is not separately argued and the rejection of claim 5 is
also affirmed.

Claim 3
Appellant argues that Raventos does not teach "instantiating an XA
interface between a transaction manager and an in-memory checkpoint
resource," as recited in claim 3, because "[p]roviding an XA interface
between a transaction manager and a resource manager . . . does not teach or
suggest instantiating an XA interface between a transaction manager and an
in-memory checkpoint resource." Br. 9. It is argued that the "resource
manager is not an in-memory checkpoint resource [for other applications]."
Br. 9.
The Examiner points to Figure 3 which shows an XA interface
between a resource manager (RM) and a transaction manager (TM), where
the resource manager is performing the checkpointing. Ans. 12.
We find that the resource manager in Raventos provides an
in-memory checkpoint resource for applications as discussed in connection
with claim 1. Figure 3A of Raventos shows an XA interface between the
transaction manager and the resource manager, which is the same as
Appellant's Figure 2. The limitation of "instantiating an XA interface
between a transaction manager and an in-memory checkpoint resource" does
Appeal 2009-002488
Application 10/880,383

8
not require a direct connection between the transaction manager and the
resource as long as the XA interface is between the transaction manager and
the resource. Again, Raventos is consistent with Appellant's Figure 2. The
rejection of claim 3 is affirmed.

Claim 4
Appellant argues that Raventos does not teach "instantiating the
in-memory checkpoint process using a TX interface call to a transaction
manager from an application program," as recited in claim 4, because while
Raventos may teach the application program communicating with the
transaction manager using a TX interface, this "does not teach or suggest
instantiating an in-memory checkpoint process using a TX interface call to a
transaction manager from an application program." Br. 9-10. It is argued
that "[w]hile the application program 301/401 communicates with the
transaction manger [sic], there is no teaching or suggestion in Raventos that
the application program 301/401 instantiates an in-memory checkpoint
process via such communication." Br. 10.
The Examiner interprets the argument to be to the "instantiating"
language and finds that instantiation is the beginning of a transaction which
is taught at 302 in Raventos. Ans. 13.
Raventos uses the X/Open DTP model. ¶ 0044. The application
program 301 defines transactional boundaries (begin, commit, or abort)
through a transactional (TX) interface 305 with a transaction manager 303.
¶ 0045; Figure 3A. The application program uses API calls to inform the
Appeal 2009-002488
Application 10/880,383

9
transaction manager of the start, end, and disposition of transactions.
¶ 0045. The transaction manager 303 and the resource manager 302
exchange transaction information over XA interface where the transaction
manager defines the protocol for transaction coordination, commitment, and
recover. ¶ 0045. Thus, the application program uses a TX interface call to a
transaction manager to instantiate a transaction and the transaction manager
is in communication with the resource manager which provides an
in-memory checkpoint process for the transaction. This appears to fully
meet the limitation of "instantiating the in-memory checkpoint process using
a TX interface call to a transaction manager from an application program."
Appellant's own system must go through the transaction manager to the
resource manager to the in-memory checkpoint process resource. The
"instantiating" limitation does not preclude the in-memory checkpoint
process from being instantiated as a by-product of handling a transaction for
the application. For these reasons, the rejection of claim 4 is affirmed.

Claims 6-13
Appellant's arguments regarding claim 6 are essentially the same as
discussed for claim 1. Accordingly, the rejection of claim 6 is affirmed for
the reasons stated with respect to claim 1. The patentability of dependent
claims 7-13 is not separately argued and therefore the rejection of
claims 7-13 is affirmed.

Appeal 2009-002488
Application 10/880,383

10
Claims 15-17 and 19
Appellant's arguments regarding claim 15 are essentially the same as
discussed for claim 1. Accordingly, the rejection of claim 15 is affirmed for
the reasons stated with respect to claim 1. The patentability of dependent
claims 16, 17, and 19 is not separately argued and therefore the rejection of
claims 7-13 is affirmed.

CONCLUSION
The rejection of claims 1, 3-13, 15-17, and 19 under 35 U.S.C.
§ 102(b) is affirmed.
Requests for extensions of time are governed by 37 C.F.R. § 1.136(b).
See 37 C.F.R. § 41.50(f).

AFFIRMED

rwk

RAYMOND R. MOSER JR., ESQ.
MOSER IP LAW GROUP/SYMANTEC CORPORATION
1030 BROAD STREET
SUITE 203
SHREWSBURY, NJ 07702