Ex Parte Rao

Board of Patent Appeals and Interferences

Jul 11, 2011

10782083 (B.P.A.I. Jul. 11, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte BINDU RAMA RAO
____________

Appeal 2009-011663
Application 10/782,083
Technology Center 2400
____________

Before LANCE LEONARD BARRY, HOWARD B. BLANKENSHIP, and
JOHN A. JEFFERY, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Appellant appeals under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-21 and 23-44. We have jurisdiction under 35 U.S.C.
§ 6(b). We reverse.

STATEMENT OF THE CASE
Appellant’s invention manages incoming access requests from
multiple electronic devices during hardware or firmware updates. See
Appeal 2009-011663
Application 10/782,083

2
generally Spec. ¶¶ 0010, 0053. Claim 1 is illustrative with key disputed
limitations emphasized:
1. A method of gracefully managing incoming access
requests during an update event from a plurality of electronic
devices in a communication network, each of the incoming
access requests comprising at least one update-related
parameter, the method comprising:

receiving each incoming access request at least
temporarily;

monitoring and evaluating the incoming access requests
using the at least one update-related parameter;

determining the availability of at least one device server
to process the incoming access requests, based upon the at least
one update-related parameter;

immediately processing incoming access requests upon
determining that the at least one device server is available; and

communicating at least one message to electronic devices
requesting access upon determining that the at least one device
server is unavailable.

The Examiner relies on the following as evidence of unpatentability:
Boivie US 6,842,783 B1 Jan. 11, 2005
(filed Feb. 18, 2000)
Peart US 6,952,714 B2 Oct. 4, 2005
(filed Oct. 2, 2001)
Vogl US 6,959,327 B1 Oct. 25, 2005
(filed Aug. 29, 2000)

Appeal 2009-011663
Application 10/782,083

3
THE REJECTIONS
1. The Examiner rejected claims 1, 3-6, 8-11, 19-21, 23-31, 35, 36, 38,
and 40-43 under 35 U.S.C. § 103(a) as unpatentable over Boivie and
Peart. Ans. 4-13.1
2. The Examiner rejected claims 13-18 under 35 U.S.C. § 103(a) as
unpatentable over Boivie and Vogl. Ans. 14-16.
3. The Examiner rejected claims 2, 7, 12, 32-34,2 37, 39, and 44 under
35 U.S.C. § 103(a) as unpatentable over Boivie, Peart, and Vogl.
Ans. 16-20.

THE OBVIOUSNESS REJECTION OVER BOIVIE AND PEART
Regarding independent claim 1, the Examiner finds that Boivie
discloses a method of managing incoming access requests during an update
event from plural electronic devices in a network with every recited feature
except for (1) monitoring and evaluating the incoming access requests using
at least one update-related parameter, and (2) determining the availability of
at least one device server to process the requests based on the parameter, but
cites Peart as teaching these features in concluding that the claim would
have been obvious. Ans. 4-5, 21-26.

1 Throughout this opinion, we refer to (1) the Appeal Brief filed December
9, 2008; (2) the Examiner’s Answer mailed February 25, 2009; and (3) the
Reply Brief filed April 27, 2009.
2 Although the Examiner indicates that claims 32-43 were rejected in the
statement of the rejection, the body of the rejection indicates that the
Examiner intended to reject claims 32-34 due to an apparent typographical
error (i.e., transposing the “3” and “4” changing “34” to “43”). See Ans. 16-
20. We therefore present the correct claim listing here for clarity.
Appeal 2009-011663
Application 10/782,083

4
Appellant argues that the cited prior art does not teach or suggest
managing incoming access requests during an update event including
monitoring and evaluating those requests using at least one update-related
parameter as claimed. According to Appellant, not only does the cited prior
art not teach or suggest an update event, let alone a parameter related to this
event, but Peart’s execution request is sent from the server to the client
which is a direction opposite from that claimed. App. Br. 7-9; Reply Br.
2-3. Appellants add that the Examiner improperly combined the cited
references since, among other things, (1) the stated motivation to combine
the references is inapplicable given the direction of traffic in Peart noted
above, and (2) the references are non-analogous. App. Br. 10-15; Reply Br.
3. The issues before us, then, are as follows:

ISSUES
Under § 103, has the Examiner erred in rejecting claim 1 by finding
that Boivie and Peart collectively would have taught or suggested managing
incoming access requests during an update event from plural electronic
devices in a network, each incoming access request comprising at least one
update-related parameter, where the incoming access requests are monitored
and evaluated using that parameter?

FINDINGS OF FACT (FF)
1. Appellant notes that new versions (updates) of firmware and
software for electronic devices (i.e., mobile electronic devices) are
periodically made available to fix bugs, introduce and delete features, etc.
Spec. ¶ 0007.
Appeal 2009-011663
Application 10/782,083

5
2. According to Appellant’s Specification:
An update may comprise firmware or software updates that
modify or change the version of a particular firmware or
software installed in the device, for example, upgrading to a
newer version, repairing a bug in the software, etc. An update
may also add new services to the electronic device or delete
services, as desired by a service provider, device manufacturer,
or an end-user.

Spec. ¶ 0053.
3. Boivie’s system enforces communications-bandwidth-based
service level agreements (SLAs) to customers hosted on a clustered web
server. To this end, requests from clients 130 arrive at a Communications
Bandwidth Manager (CBM) 110 via input link 241 and are queued in
queuing system 360. Based in part on data monitored from outgoing data
path 160 via the CBM’s traffic estimator 340, the CBM’s scheduler 350 (1)
selects a request in the queuing system; (2) determines the server node to
service the request; and (3) sends the selected request to the server node via
link 280. Boivie, Title; Abstract; col. 1, ll. 10-14; col. 5, l. 14 – col. 7, l. 17;
Figs. 1-3.
4. Peart’s system automatically executes a program associated with a
data file when the data file and executable program are located on different
computing nodes (e.g., client and server). Peart, Abstract; col. 1, ll. 7-13.
5. Peart’s web-based file-type association (FTA) embodiment enables
transparent program execution on a server node by selecting graphical
indicia presented on a client node that represent data files located on a web
server. As shown in Figure 10A, after the client node receives a selection of
a graphically-depicted data file, the client node provides this selection to the
web server (steps 280-288). The client node then receives a request to
Appeal 2009-011663
Application 10/782,083

6
execute a first executable program (i.e., an execution request) (step 292),
where the request includes parameters that (1) refer to the first and second
executable programs, and (2) identify the selected data file on the web
server. The client then executes the first program, and sends a request to
execute the second program to the server (steps 296-300). Peart, col. 29, l. 5
– col. 30, l. 5; col. 30, ll. 37-47; Fig. 10A.
6. In one embodiment, the parameter identifying the selected data file
is provided directly to the server node. Peart, col. 30, ll. 30-35.
7. In one embodiment, the web server uses mappings which specify
an association between a selected data file and executable programs. These
mappings are received in groups or aggregated with other data such as
software updates. The mappings can be updated either periodically or as
needed. Peart, col. 31, ll. 45-67.
8. Using received mapping information, the web server constructs
and transmits an execution request to the client node, which the client node
later executes. Peart, col. 32, ll. 1-4; Fig. 10B (step 324).
9. Peart notes in connection with the client-based FTA embodiment
that mappings and rules can be distributed over a live telecommunications
link and in real-time while the client and server nodes are used. Peart, col.
23, ll. 18-28.

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, managing incoming access requests during an update event from plural
electronic devices in a network, each incoming access request comprising at
Appeal 2009-011663
Application 10/782,083

7
least one update-related parameter, where the incoming access requests are
monitored and evaluated using that parameter. We emphasize the term
“during an update event” here, for we find the Examiner’s reliance on Boivie
for teaching managing incoming access requests during an update event
(Ans. 4) problematic.
In the Specification, Appellant describes updating in terms of
providing new versions of firmware or software, or adding or deleting
device services. FF 1-2. Although these types of updates are indicated in
permissive terms (FF 2), they nonetheless inform our construction of the
term “update event” which, when considered in light of the disclosure,
means an event associated with (1) providing new versions of electronic
device firmware or software, or (2) adding or deleting device services.
Boivie, however, simply does not disclose an “update event” when
construed in this context, let alone manage incoming access requests during
such an event as claimed. Rather, Boivie enforces bandwidth-based SLAs
by (1) queuing incoming requests, and (2) selecting particular queued
requests and sending them to selected server nodes based on monitoring
outgoing data. FF 3. Boivie simply has nothing to do with updating. To the
extent that the Examiner construes Boivie’s client-server data exchange or
automatically selecting a particular request and corresponding server node as
somehow constituting an “update” is problematic, for neither interpretation
reasonably comports with an “update event” when construed in light of the
specification as noted above.
Nor does the Examiner’s reliance on Peart cure this deficiency. That
said, the Examiner is correct that Peart sends a parameter identifying a
selected data file directly to the server node (Ans. 21; FF 6) which teaches
Appeal 2009-011663
Application 10/782,083

8
sending parameters from client to server. Appellant’s arguments regarding
Peart’s sending execution requests from the server to the client which is a
direction opposite from that claimed (App. Br. 7-9; Reply Br. 2-3)—while
correct (see FF 4)—simply do not address Peart’s alternative embodiment
indicated by the Examiner noted above.
Moreover, the Examiner’s reliance on Peart’s mapping information
(Ans. 22) has some merit, for Peart’s server uses mappings to construct and
transmit execution requests. FF 7-8. Not only can these mappings be
included in software updates, but the mappings themselves can also be
updated. FF 7. In this regard, the Examiner’s point (Ans. 22) that
associated parameters would at least be related to these updates is well
taken, for that is all the claim requires by reciting, somewhat broadly, an
update-related parameter.
But despite these update-related parameters in Peart, we still fail to
see how incoming access requests containing these parameters would be
managed during an update event as claimed—a crucial temporal
requirement. Peart does, however, indicate in connection with a different
embodiment that mappings can be distributed in real time and while the
client and server nodes are used. FF 9. And as noted above, mappings are
associated with update events. See FF 7. But we cannot say that this teaches
or suggests managing incoming access requests during an update event as
claimed, for the server receives mappings (and their associated updates)
before receiving and processing requests from the client. See FF 5-8.3

3 Accord Peart, Fig. 9B (illustrating a server-side FTA embodiment where
the mapping is received at the server before receiving stored data file
selection from client).
Appeal 2009-011663
Application 10/782,083

9
Therefore, even if the references were combinable as the Examiner
asserts, they still do not teach or suggest managing incoming access requests
during an update event from plural electronic devices in a network, each
incoming access request comprising at least one update-related4 parameter,
where the incoming access requests are monitored and evaluated using that
parameter. Since this deficiency is dispositive of the issue before us, we
need not address Appellant’s arguments regarding the references’
combinability. App. Br. 10-15; Reply Br. 3.
We are therefore persuaded that the Examiner erred in rejecting (1)
independent claim 1; (2) independent claims 19 and 42 which recite
commensurate limitations; and (3) dependent claims 3-6, 8-11, 20, 21, 23-
31, 35, 36, 38, 40, 41, and 43 for similar reasons.

THE OTHER OBVIOUSNESS REJECTIONS
Since the Examiner has not shown that Vogl cures Boivie’s
deficiencies regarding managing incoming access requests during an update
event noted previously, we likewise reverse the Examiner’s rejection of (1)
claims 13-18 over Boivie and Vogl (Ans. 14-16), and (2) claims 2, 7, 12, 32-
34, 37, 39, and 44 over Boivie, Peart, and Vogl (Ans. 16-20) for similar
reasons.

4 Although independent claim 42 recites a selection-related parameter
instead of an update-related parameter, our reversal nonetheless applies to
claim 42 as well.
Appeal 2009-011663
Application 10/782,083

10
CONCLUSION
The Examiner erred in rejecting claims 1-21 and 23-44 under § 103.

ORDER
The Examiner’s decision rejecting claims 1-21 and 23-44 is reversed.

REVERSED

pgc