Ex Parte Gimness et al

Board of Patent Appeals and Interferences

Jul 1, 2011

10991271 (B.P.A.I. Jul. 1, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte JOSEPH ANDREW GIMNESS,
BRIAN SEAN MCCAIN, and JASON LEE PEIPELMAN
____________

Appeal 2009-010342
Application 10/991,271
Technology Center 2100
____________

Before LANCE LEONARD BARRY, JOHN A. JEFFERY, and DENISE M.
POTHIER, Administrative Patent Judges.

POTHIER, Administrative Patent Judge.

DECISION ON APPEAL
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1, 2, 5, 8-11, 15, 17-19, 22, 25, 26, 29, and 30. We have
jurisdiction under 35 U.S.C. § 6(b). We reverse.

STATEMENT OF THE CASE
Appellants’ invention relates to converting a synchronous interface
into an asynchronous interface. See generally Spec. ¶ 0001. Claim 1 is
reproduced below with some key disputed limitations emphasized:
Appeal 2009-010342
Application 10/991,271

2
1. An apparatus to convert a synchronous interface into an
asynchronous interface, the apparatus comprising:
a receive module comprising executable code stored on a
storage device, executed by a processor, and configured to receive a
request for a transaction from a synchronous requestor;
a generate module comprising executable code stored on the
storage device, executed by the processor, and configured to generate
a delaying object and a forwarding interface compatible with a
requested return type, wherein the delaying object is configured as
[an] IOU object defined by a JAVA® IOU data class and performs a
standby() operation indicating that the transaction is in process; and
a return module comprising executable code stored on the
storage device, executed by the processor, and configured to return the
delaying object with the forwarding interface to the requestor;
a satisfy module comprising executable code stored on the
storage device, executed by the processor, and configured to satisfy
the request for the transaction from the synchronous requestor by
recognizing the delaying object as a completed transaction until the
transaction is available for completion wherein the requestor
continues to process other transactions until the transaction is
available for completion;
a notification module comprising executable code stored on
the storage device, executed by the processor, and configured to notify
the synchronous requestor via the delaying object when the
transaction is available for completion; and
an initiation module comprising executable code stored on
the storage device, executed by the processor, and configured to
initiate a second request for the transaction via the delaying object
when the transaction is available for completion.

The Examiner relies on the following as evidence of unpatentability:
Laakso US 5,170,476 Dec. 8, 1992
Shkvarchuk US 2005/0234928 A1 Oct. 20, 2005
(filed Mar. 23, 2004)

Appeal 2009-010342
Application 10/991,271

3
Allan Vermeulen, An Asynchronous Design Pattern 1-81 (1996), available at
http://drdobbs.com/java/184409898 (“Vermeulen”).

THE REJECTION
The Examiner rejected claims 1, 2, 5, 8-11, 15, 17-19, 22, 25, 26, 29,
and 30 under 35 U.S.C. § 103(a) as unpatentable over Shkvarchuk, Laakso,
and Vermeulen. Final Rej. 3-18; Ans. 4-14.2

THE CONTENTIONS
Regarding independent claim 1, the Examiner finds that Shkvarchuk
discloses all recited limitations, except for the satisfy module, the initiation
module, and the delaying object configured as an IOU object. Final Rej. 3-
5. The Examiner relies on Laakso to teach the satisfy and initiation modules
and Vermeulen to teach the delaying object configured as an IOU object as
recited. Final Rej. 5-7.
Appellants argue, among other things, that Shkvarchuk does not
disclose or teach a generate module configured to generate a delaying object
that is an IOU object, and that Vermeulen does not teach or suggest an IOU
object and the forwarding interface compatible with the requested return
type. See App. Br. 19; Reply Br. 6. Appellants also assert that Laakso
teaches a new request and fails to teach or suggest an initiation module

1 Eight printed pages of this reference were provided, and these page
numbers correspond sequentially to the pages provided.
2 Throughout this opinion, we refer to (1) the Final Rejection mailed
December 11, 2007; (2) the Appeal Brief filed June 23, 2008; (3) the
Examiner’s Answer mailed September 29, 2008; and (4) the Reply Brief
filed December 1, 2008.
Appeal 2009-010342
Application 10/991,271

4
configured to initiate a second request for the transaction from a
synchronous requestor. App. Br. 17-18; Reply Br. 4-5.

ISSUES
Under § 103, has the Examiner erred in rejecting claim 1 by finding
that Shkvarchuk, Laakso, and Vermeulen collectively would have taught or
suggested:
(1) a generate module configured to generate a delaying object and a
forwarding interface, the delaying object configured as an IOU object?
(2) an initiation module configured to initiate a second request for the
transaction from a synchronous requestor?

FINDINGS OF FACT (FF)
1. Shkvarchuk discloses synchronous requestor 102 requesting
information from an asynchronous web service 108 through an integration
services network 106. The request is sent to the web service 108 for
processing though a synchronous post interface 202, a receive queue 204, a
route 206, a delivery queue 208, and a push 210. The response is sent
through the network 106 using post interface 212, receive queue 214, route
216, delivery queue 218, and post interface 202. Shkvarchuk, ¶¶ 0037-38;
Fig. 2.
2. Vermeulen discusses adding asynchronous behavior to
applications. Synchronous functions return an object to a caller, and in the
asynchronous case, the function returns an IOU object to their callers.
Vermeulen 1.
Appeal 2009-010342
Application 10/991,271

5
3. Laakso teaches the bus interface controller (BIC) 16 continues
loading cache 34 with incoming data (LW2, LW3) from the previous burst
request during the next prefetch request. Laakso, col. 5, ll. 65-68; Figs. 1-2.

ANALYSIS
Based on the record before us, we find error in the Examiner’s
obviousness rejection of independent claim 1 which calls for, in pertinent
part, a generate module configured to generate a delaying object and a
forwarding interface, the delaying object is configured as an IOU object.
The Examiner maps Shkvarchuk’s queues (e.g., 204, 208, 214, 218) to the
delaying object and Shkvarchuk’s routes (e.g., 206, 216) to the forwarding
interface (FF 1), and admits Shkvarchuk does not disclose the delaying
object as an IOU object. See Final Rej. 3-5; Ans. 15, 17. The Examiner
then cites to Vermeulen to teach that the delaying object is an IOU object.
See Final Rej. 5-6; Ans. 12, 17. The rejection, however, does not explain
whether the Examiner is proposing to modify Shkvarchuk’s delaying object
into a Vermeulen IOU-type delaying object or adding Vermeulen’s delaying
object to Shkvarchuk’s system. See Final Rej. 5-7. We therefore are left to
speculate as to the Examiner’s position.
If the Examiner is suggesting to modify Shkvarchuk’s queues (i.e., the
Examiner’s elected delaying objects) to be an IOU object based on
Vermeulen’s teaching, such a combination changes or destroys each of
Shkvarchuk queue’s principle of operation from being a device for receiving
and buffering information (FF 1) to being an object actually returned to a
caller (FF 2). We find such a combination would render Shkvarchuk’s
queues inoperable. On the other hand, if the Examiner intended to add
Appeal 2009-010342
Application 10/991,271

6
Vermeulen’s different delaying object to Shkvarchuk’s existing system as an
IOU-type object, as taught by Vermeulen, we are at a loss as to the
discussions of Shkvarchuk’s queues as the delaying object (see Final Rej. 3-
4; Ans. 15). Nonetheless, such an addition does teach a delaying object
configured to be generated as an IOU object (FF 2) and Shkvarchuk teaches
the recited forwarding interface (e.g., 206, 216 (FF 1)). The record,
however, does not adequately demonstrate that combining these teachings
would predictably yield the same generate module configured to generate
both Shkvarchuk’s forwarding interface and Vermeulen’s delaying object as
an IOU object as claim 1 requires.
Appellants also assert that Laakso does not teach or suggest an
initiation module configured to initiate a second request for the transaction
from the synchronous requestor through the delaying object when the
transaction is available for completion. App. Br. 17-18; Reply Br. 4-5. We
agree. The Examiner relies on Laakso’s teaching (see Final Rej. 5-6) of
sending out the next prefetch request while the data from the previous
request is still loading into a cache (FF 3) to teach this limitation. There is
no discussion of initiating a second request for the transaction (e.g., the
previous request) as required by claim 1, and Laakso does not teach or
suggest using the delaying object that is configured as an IOU object for
initiating this second request. See id. Nor would combining this teaching
with Shkvarchuk and Vermeulen, as the Examiner proposes, cure such a
deficiency. The combination teaches and suggests initiating new requests
before the previous request is complete or pipelining. See Final Rej. 6. The
combination, as proposed by the Examiner, does not therefore teach or
suggest an initiation module configured to initiate a second request for the
Appeal 2009-010342
Application 10/991,271

7
transaction via or through the delaying object when the transaction is
available for completion.
For the foregoing reasons, Appellants have persuaded us of error in
the obviousness rejection of: (1) independent claim 1; (2) independent
claims 9, 10, 18, 26, and 30 which recite commensurate limitations; and (3)
dependent claims 2, 5, 8, 11, 15, 17, 19, 22, 25, and 29 for similar reasons.

CONCLUSION
The Examiner erred in rejecting claims 1, 2, 5, 8-11, 15, 17-19, 22,
25, 26, 29, and 30 under § 103.

DECISION
The Examiner’s decision rejecting claims 1, 2, 5, 8-11, 15, 17-19, 22,
25, 26, 29, and 30 is reversed.

REVERSED

tj