Ex Parte Wookey et al

Board of Patent Appeals and Interferences

Mar 30, 2009

10067165 (B.P.A.I. Mar. 30, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
_____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
_____________

Ex parte MICHAEL J. WOOKEY, TREVOR WATSON,
and JEAN CHOUANARD
_____________

Appeal 2008-3105
Application 10/067,165
Technology Center 2400
______________

Decided: 1 March 30, 2009
_______________

Before JOHN C. MARTIN, LEE E. BARRETT, and
LANCE LEONARD BARRY, Administrative Patent Judges.

MARTIN, Administrative Patent Judge.

DECISION ON APPEAL

1 The two-month time period for filing an appeal or commencing a
civil action, as recited in 37 C.F.R. § 1.304, begins to run from the decided
date shown on this page of the decision. The time period does not run from
the Mail Date (paper delivery) or Notification Date (electronic delivery).

Appeal 2008-3105
Application 10/067,165

2
STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-18, which are all of the pending claims.
We have jurisdiction under 35 U.S.C. § 6(b). We affirm.

A. Appellants’ invention
Appellants’ invention relates to remote service delivery for computer
networks. Specification 2:24-25.
By way of background, Appellants explain that in a remote services
system, often large numbers of messages are sent to multiple destinations of
the customer, for example, when a remote services system needs to push a
software update to all of the customer components. Id. at 3:9-12. The
transfer of a large number of messages from the remote services system to a
customer site may waste network resources, as these messages tend to be
large (e.g., several Mbytes of data). Id. at 3:12-14.
Appellants’ Figure 11 is reproduced below.
Appeal 2008-3105
Application 10/067,165

3

Figure 11 shows a flow diagram of communications within a remote
services architecture. Id. at 19:17-18. Communications within the remote
service architecture involve three tiers: a remote services proxy tier 1110, an
intermediate MLM (mid level manager2) tier 1112, and an application MLM
and server tier 1114. Id. at 19:19-21. Communication is established and
connections are made from the bottom tier (the remote services proxy tier) to
the top tier. Id. at 19:21-22.
In Appellants’ method, when a message is originated at an application
server of the remote services system for a group of destinations, a single
instance of a message is transferred from the application server to an
intermediate MLM on the path of the group of components. Id. at 3:19-22.

2 Specification 8:9.
Appeal 2008-3105
Application 10/067,165

4
The intermediate MLM duplicates the message for all of the final
destinations and transmits the message. Id. at 3:22-23. Thus, the network
resources used between the application server and the multiple destinations
are minimized as no redundant transfer occurs between the application
server and the intermediate MLM. Id. at 3:23-25.
In one embodiment, to which the claims are directed, the invention
relates to communicating in a remote services system that includes a forward
channel communication and a back-channel communication. Id. at 3:28-30.
The forward channel communicates using a forward channel
communication path and the back-channel communicates using a back-
channel communication path, which is established only after a forward
channel communication path is established. Id. at 3:30-33. The back-
channel communication path is used to multicast a message to a group of
components. Id. at 3:33-34.

B. The claims
The independent claims are claims 1, 7, and 13, of which claim 1
reads:
1. A method of communicating in a remote services system
comprising:
communicating a forward channel communication using
a forward channel communication path;
communicating a back-channel communication using a
back-channel communication path, the back-channel
Appeal 2008-3105
Application 10/067,165

5
communication path being established only after a forward
channel communication path is established; and
using the back-channel communication path to multicast
a message to a group of remote service components.
Claims App., Br. 16 (formatting modified).3

Claim 7 reads as follows:
7. A method of communicating in a remote services
system comprising:
assigning a plurality of remote service components
within the remote services system with a respective plurality of
unique remote services identifiers;
communicating a forward channel communication using
a forward channel communication path;
communicating a back-channel communication using a
back-channel communication path; and
using the back-channel communication path to multicast
a message to a group of remote services components based
upon unique remote services identifiers corresponding to
components of the group of remote service components.
August 3, 2005, “Response to Non-final Office Action” at 4-5 (formatting
modified).4

3 References herein to the Brief are to the Amended Brief filed
January 14, 2008. No Reply Brief was filed.
4 As noted in the Answer (at 3), the copy of claim 7 as reproduced in
the Claims Appendix (Br. 16-17) is inaccurate because it corrects the second
(Continued on next page.)
Appeal 2008-3105
Application 10/067,165

6
C. The references and rejections
The Examiner relies on the following references:
Kamentsky et al. (Kamentsky) US 2002/0065929 May 30, 2002
Dyer et al. (Dyer) US 6,349,340 B1 Feb. 19, 2002

Claims 1, 2, 5-8, 11-14, 17, and 18 stand rejected under 35 U.S.C.
§ 102(e) for anticipation by Dyer. Answer 4.
Claims 3, 4, 9, 10, 15, and 16 stand rejected under § 103(a) for
obviousness over Dyer in view of Kamentsky. Id. at 7.
Claims 7-12 further stand rejected under § 112, second paragraph, for
being indefinite due to the above-noted inconsistency in the use of the terms
“remote service” and “remote services” in claim 7. Id. at 4.
In the Brief, Appellants state that “[t]he rejections of Claims 1, 7, and
13 under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No.
6,349,340 by Dyer are the only rejections at issue in this Appeal” (Br. 3) and
thus argue the merits of only the § 102(e) rejection of independent claims 1,
7, and 13. Id. at 3. However, Appellants further explain that “[a]s claims 2-
6, 8-12 and 14-18 depend from claims 1, 7 and 13 respectively, the rejection
of these claims under 35 U.S.C. § 102(e) or 35 U.S.C. § 103(a) is also
without foundation” (id. at 15), making it clear that Appellants do not intend
to concede the unpatentability of claims 2-6, 8-12 and 14-18 under § 102(e)
or § 103(a). We are accordingly treating the rejections of those dependent

of the three underlined phrases to read “remote service.”
Appeal 2008-3105
Application 10/067,165

7
claims as standing or falling with the § 102(e) rejection of respective parent
claims 1, 7, and 13.
Appellants’ discussion of the § 102(e) rejection of claims 1, 7, and 13
addresses those claims in two groups, the first group consisting of claim 1
(Br. 10-13) and the second group consisting of claims 7 and 13. Id. at 13-15.
Regarding the § 112 rejection of claims 7-12, Appellants state:
The Appellant acknowledges a typographical error in
claim 7 fostering a rejection of claims 7-12 under 35 U.S.C.
§ 112. While not an issue for the purposes of this appeal,
Appellant acknowledges the mistake and upon resolution of this
appeal will propose an amendment to rectify this deficiency.
Br. 3. Because Appellants have not shown error in the Examiner’s § 112
rejection of claims 7-12, we are summarily affirming their rejection on that
ground.

THE ISSUE
Appellants have the burden to show reversible error by the Examiner
in maintaining the rejections. See In re Kahn, 441 F.3d 977, 985-86 (Fed.
Cir. 2006) (“On appeal to the Board, an applicant can overcome a rejection
by showing insufficient evidence of prima facie obviousness or by rebutting
the prima facie case with evidence of secondary indicia of
nonobviousness.”) (quoting In re Rouffet, 149 F.3d 1350, 1355 (Fed. Cir.
1998)).
The sole issue is whether Appellants have shown that the Examiner
erred in reading the claimed “forward channel communication using a
Appeal 2008-3105
Application 10/067,165

8
forward channel communication path” on Dyer’s communication of a
request for data from a client node to a server and in reading the claimed
“back-channel communication using a back-channel communication path”
on Dyer’s communication of the requested data over a source
communication channel to a plurality of client nodes.

PRINCIPLES OF LAW
“To anticipate a claim, a prior art reference must disclose every
limitation of the claimed invention, either explicitly or inherently.” In re
Schreiber, 128 F.3d 1473, 1477 (Fed. Cir. 1997).

ANALYSIS
Dyer discloses a method for providing improved performance in
networks using multicast technology. Dyer, col. 1, ll. 14-16.
Dyer’s Figure 1 shows a plurality of client computers 2 connected
through a LAN 4 to a server 6 (id., col. 4, ll. 23-27), which is an application
server computer system having a network operating system for serving files
for clients connected to the network 4. Id., col. 5, ll. 29-31.
Dyer’s Figure 3 is reproduced below.
Appeal 2008-3105
Application 10/067,165

9

Figure 3 is a high level architecture of a typical network client node 2
in Figure 1 showing network application software 20 and network interface
circuitry 10 (id., col. 5, ll. 41-43), labeled “TCP/IP Hardware” in Figure 3.
Requests for data are initiated by processes 28. See id., col. 5, ll. 52-53
(“[E]ach process 28 can request data cataloged in the data distribution
library 26.”) (bolding omitted).
The interface circuitry 10 includes up to sixty-four addressable
Appeal 2008-3105
Application 10/067,165

10
channels 22 for receiving and transmitting data streams onto the LAN 4. Id.,
col. 6, ll. 15-18. The data distribution manager 24 distributes only the
requested data to the requesting processes 28 by performing filtering in the
TCP/IP hardware 10 (i.e., by disabling unwanted channels) and by
performing software filtering in data distribution manager 24. Id., col. 7, ll.
7-10. The hardware channels 22 to be enabled and disabled are determined
either statically or dynamically by data distribution manager 24. Id., col. 7,
ll. 10-19. In the static solution, a configuration file can be created in the data
distribution manager 24 to include a static mapping of data domains
corresponding to the requested data to hardware channels 22. Id., col. 7, ll.
20-23. Thus, upon a request for data by a process 28, the data distribution
manager 24 need only consult the configuration file to determine an
appropriate channel 22 to enable in the interface circuitry 10. Id., col. 7,
ll. 23-26.
Several dynamic solutions are disclosed (id., col. 7, ll. 35-36). In one
dynamic solution, apparently relied on by the Examiner, “the data
distribution manager 24 can receive a point-to-point message from the
source of the requested data identifying an appropriate channel 22 though
which the data distribution manager 24 can receive the requested data.” Id.,
col. 7, ll. 36-40 (bolding omitted). See also id., col. 2, ll. 47-50; id., col. 7,
ll. 15-19. The message identifying an appropriate channel presumably is
issued in response to a request for data communicated over a channel 22
from the client to the server. Although the Examiner did not specifically
Appeal 2008-3105
Application 10/067,165

11
rely on the above-cited passages addressing a dynamic solution, those
passages appear to provide the basis for Dyer’s statement that “[e]ach of the
requests for data and requested data can be communicated between the
processes 28 and the LAN 4 through channels 22 leading to and from the
interface circuitry 10” (id., col. 5, ll. 54-57) (bolding omitted, emphasis
added), on which statement the Examiner does rely, citing it as a basis for
finding that the claimed “communicating a forward channel communication
using a forward channel communication path” reads on Dyer’s use of a
“channel for receiving client request or subscription for multicast.” Final
Action 3, para. 7b. Also, the Examiner specifically explains that “Dyer's
disclosure includes the teachings of processes and steps of a source server
receiving requests from client nodes for data, establishing a source
communication channel with the client nodes and multicast the requested
data to client nodes.” Answer 8-9 (emphasis added). It is therefore clear
that the request on which the Examiner reads the claimed “forward channel
communication” is the request for data communicated from the client node
though channels 22 to the server and not the “request” referred to in the
following passage, which is a request for data sent by a process 28 to the
data distribution manager 24 within a client node:
The method can include receiving from a process in a
client node a request for multicast data; identifying a source for
the requested multicast data; determining a source
communications channel for receiving the requested multicast
data; enabling the source communications channel; receiving
the multicast data through the source communications channel;
Appeal 2008-3105
Application 10/067,165

12
and, forwarding the multicast data to the requesting client node
process.
Dyer, col. 2, ll. 31-38.
The Examiner reads the claimed “back-channel communication using
a back-channel communication” on “determining and enabling the source
communication channel for receiving the requested multicast data.” Final
Action 3, para. 7b. In the above-discussed dynamic solution, the server
responds to a request for data sent from a client node to the server by
informing the client node of the identity of the source communication
channel that will carry the requested data.
Regarding the last step of claim 1 (“using the back-channel
communication path to multicast a message to a group of remote service
components”), the Examiner explained that “once the client is subscribed to
the data distribution service, server multicast message [sic] to all subscribing
clients.” Final Action 3, para. 7c. Although column 2, lines 31-30 of Dyer,
cited as support (id.), describe “forwarding the multicast data to the
requesting client node process,” which occurs inside a client node, at page 9
of the Answer the Examiner additionally relies on Dyer’s disclosure that “in
the preferred embodiment, the server 5 sends to each client node 2 all
multicast data without regard to the requirements of each client node 2,”
citing column 6, lines 1-3. It is therefore clear that the Examiner is reading
the claimed “group of remote service components” on a plurality of client
nodes 2 rather than on the plurality of processes 28 within a client node.
Appellants, after quoting Dyer’s above-quoted passage (col. 2, ll. 31-
Appeal 2008-3105
Application 10/067,165

13
38) that includes describing Dyer’s method as including “forwarding the
multicast data to the requesting client node process,” argue that the rejection
is improper because “the channel used to forward the multicast data appears
to be the same channel upon which the request arrived” (Br. 11-12)
(emphasis added). This argument is unconvincing because it is incorrectly
assumes that the Examiner is reading the claimed “forward channel” and
“back-channel” on communications between processes 28 and data
distribution manager 24 within a client node. Instead, as explained above,
the Examiner reads the claimed “forward channel communication” on a
request sent from client node 2 to the server 6a reads the claimed “back-
channel communication path” that is used “to multicast a message to a group
of remote service components” on Dyer’s use of a source communication
channel to send multicast data to a plurality of client nodes 2.
As Appellants have not shown error in the Examiner’s rejection of
claim 1, we are affirming the rejection of that claim. Because Appellants
have not separately argued the merits of the rejections of claims 2-6, which
depend on claim 1, we are also affirming the rejections of those claims.
37 C.F.R. § 41.37(c)(1)(vii) (2007); In re Nielson, 816 F.2d 1567, 1572
(Fed. Cir. 1987).
Turning now to independent claims 7 and 13, which are argued as a
group, we elect for consideration claim 7.
The Examiner (Answer 5, para. e) reads the “unique remote services
identifiers” recited in the “assigning” step on Dyer’s disclosure that the
Appeal 2008-3105
Application 10/067,165

14
configuration file used by data distribution manager 24 to identify the source
for requested multicast data “can include a static mapping of any identifier
corresponding to a source of the requested multicast data, for example a
proprietary network address or a network adapter address corresponding to
the network source of the multicast data.” Dyer, col. 7, ll. 28-33. Appellants
agree that Dyer teaches that an IP address or subscriber ID/information is
evidence of a respective unique remote service identifier (Br. 15) but argue
that “Dyer, as discussed above, associates these identifiers with the forward
channel, not the back-channel as is claimed.” Id. (underlining omitted).
This argument is unconvincing for the reasons given in the above discussion
of claim 1.
For the foregoing reasons, we are affirming the § 102(e) rejection of
claims 7 and 13. Because Appellants have not separately argued the merits
of the rejections of claims 8-12 and 14-18, which depend on claims 7 and
13, respectively, we are also affirming the rejections of those claims.

DECISION
The Examiner’s decision that claims 1-18 are unpatentable over the
prior art is affirmed, as is the Examiner’s decision that claims 7-12 are
unpatentable under the second paragraph of 35 U.S.C. § 112.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(1)(iv) (2008).
Appeal 2008-3105
Application 10/067,165

15

AFFIRMED

msc

Sun Microsystems, Inc
c/o Marsh Fischmann & Breyfogle LLP
8055 East Tufts Avenue
Suite 450
Denver, CO 80237