Ex Parte Barbir et al

Board of Patent Appeals and Interferences

Jun 14, 2010

10013677 (B.P.A.I. Jun. 14, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte ABDULKADEV BARBIR,
NICOLAS C. BENNETT,
and NALIN N. MISTRY
____________

Appeal 2009-005967
Application 10/013,677
Technology Center 2400
____________

Decided: June 14, 2010
____________

Before JOHN A. JEFFERY, JAMES D. THOMAS, and
JAMES R. HUGHES, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1 and 3-12. Claim 2 has been canceled. App. Br. 9. We
have jurisdiction under 35 U.S.C. § 6(b). We affirm.

Appeal 2009-005967
Application 10/013,677

2
STATEMENT OF THE CASE
Appellants invented a method for redirecting content requests between
peers. See generally Spec. 1, 4. Claim 1 is reproduced below with the key
disputed limitations emphasized:
1. A method of redirecting content requests among content
distribution network peers comprising the steps of:

establishing a content distribution network peering hierarchy;

for each content network peer, establishing a content distribution
table;

populating the content distribution tables when distributing
content;

at a given content distribution peer, establishing a plurality of
levels of peering for content distribution network peers of a content
space;

if unable to service the request at the content distribution peer
because of lack of capacity, referring to the content distribution table
to find a neighbouring peer having the requested content; and

redirecting, by the content distribution peer, the request to the
neighbouring peer by appending an address of the neighbour peer to
the first address for providing a log of previous peers.

The Examiner relies on the following as evidence of unpatentability:
Feldman US 6,055,561 Apr. 25, 2000
McCanne (McCanne II)1 US 6,415,323 B1 July 2, 2002
(filed Dec. 9, 1999)
McCanne (McCanne I) US 6,785,704 B1 Aug. 31, 2004
(filed July 3, 2000)

1 This patent is incorporated by reference in McCanne I. See McCanne I,
col. 1, ll. 20-24.
Appeal 2009-005967
Application 10/013,677

3
THE REJECTION
The Examiner rejected claims 1 and 3-12 under 35 U.S.C. § 103(a) as
unpatentable over McCanne I, McCanne II, and Feldman. Ans. 2-6.2

CLAIM GROUPING
Appellants argue claims 1 and 73 together as a group (see App. Br.
4-8) and state claims 3-6 and 8-12 are allowable for the same reasons as
claims 1 and 7 (App. Br. 8). Accordingly, we select claim 1 as
representative of that group. See 37 C.F.R. § 41.37(c)(1)(vii).

THE CONTENTIONS
Regarding representative independent claim 1, the Examiner finds that
McCanne I and II teach all the limitations, except for appending the
neighboring peer’s address to a first address to provide a log. Ans. 2-3. The
Examiner relies on Feldman’s discussion of appending identifiers to a
message to modify McCanne I’s redirection process and create a log (e.g.,
identifiers in the path) to prevent loop formations. Ans. 3.
Appellants argue that McCanne I’s “anycast” technique fails to teach
redirecting the request between neighboring peers in case of overload, and
McCanne II does not cure this deficiency. App. Br. 5-8; Reply Br. 4-10. In

2 Throughout this opinion, we refer to (1) the Appeal Brief filed January 28,
2008; (2) the Examiner’s Answer mailed May 7, 2008; and (3) the Reply
Brief filed June 26, 2008. Although the pagination of the Examiner’s
Answer is inconsistent (e.g., the fourth page is unnumbered, and pages
following that page begin with page 2), we nonetheless refer to the pages in
the order in which they appear in the record for clarity.
3 While the argument’s heading refers to claim 6 (App. Br. 4), the content of
the arguments addresses the scope of claim 7.
Appeal 2009-005967
Application 10/013,677

4
particular, Appellants contend that McCanne I teaches redirection by
referring back to the client or trying different peers and not passing
responsibility and the request on to a peer as recited. App. Br. 5-6; Reply
Br. 5-6. Appellants further assert that McCanne II’s Figure 6 fails to teach
redirecting a request from a content peer. Reply Br. 11.
The issue before us, then, is as follows:

ISSUE
Under § 103, has the Examiner erred in rejecting claim 1 by finding
that McCanne I, McCanne II, and Feldman collectively would have taught or
suggested the content distribution peer redirecting the request to the
neighboring peer because of lack of capacity?

FINDINGS OF FACT (FF)
1. McCanne I teaches an Administratively Provisioned Interdomain
Anycast Routing-Domain Name Server (APAR-DNS) redirection
architecture technique. APAR-DNS servers or nodes (e.g., N1*, N2*, and
N3*) are deployed within the content backbone and configured with the
APAR anycast address N*. Co-located with each APAR-DNS server are
content servers (S1, S2, and S3) that are situated near Internet Service
Provider’s (ISP’s) peering points, which allow the system to know the
closest peering point for the client requesting service. McCanne I, col. 14,
ll. 47-48, 64-65; col. 17, ll. 60-62; col. 18, ll. 56-63; Fig. 13.
2. McCanne I explains that the server preferentially returns address
S2 for the requested name for a client request that arrives at N2*. If S2 is
overloaded, N2* will be informed and redirect the client to alternate servers
Appeal 2009-005967
Application 10/013,677

5
(e.g., S1 or S3). N2* is informed of an overloading state either by querying
the load on S2 or by some other agent. McCanne I, col. 18, l. 63-col. 19, l.
3; Fig. 13.
3. McCanne I discloses two different redirection embodiments. One
redirection technique is an explicit redirection embodiment while the other
technique is an incremental deployment of redirection. McCanne I, col. 7, ll.
31-32, 37-38; col. 19, ll. 56-58; col. 20, ll. 14-49; Figs. 13, 15.
4. McCanne II discloses a process of delivering content to a client
(e.g., 802). In one embodiment, client 802 sends request 820 to anycast
referral node (ARN) 804, which redirects client 802 to service node 806.
Client 802 transmit request 824 to node 806, which requests a channel by
sending message 826 to node 808 using the client request. Content flows
from node 808 to client 802 using path 828. When node 806 fails, ARN 804
directs client to node 810, which sends message 836. Content flows to client
through 838. McCanne II, col. 16, l. 47 - col. 17, l. 18; Fig. 6.

ANALYSIS
We begin by construing the key disputed limitations of representative
independent claim 1 which calls for, in pertinent part, “redirecting, by the
content distribution peer, the request to the neighboring peer . . . for
providing a log of previous peers.” Such redirection occurs when the
content distribution peer lacks capacity and refers to a content distribution
table to find a neighboring peer having the requested content according to
claim 1. Contrary to Appellants’ contentions (App. Br. 5-6), claim 1 does
not require a further step of continuing to redirect to another peer in a daisy
chain until an available peer is reached or the peers are exhausted. In fact,
Appeal 2009-005967
Application 10/013,677

6
claim 1 covers a scenario where the request is redirected only once to a first
neighboring peer that contains the requested content and appends the
neighboring peer’s address to provide a log of the previous peers. In this
case, the original content distribution peer having insufficient capacity is the
only previous peer. We therefore disagree with Appellants (Reply Br. 8-9)
that the only reasonable interpretation of claim 1 must include repeating the
redirection steps to different content distribution peers in a daisy chain
manner and that there could be no log of the previous peers unless redirected
in a daisy chain manner.
Moreover, while claim 1 requires that the request be redirected to a
neighboring peer by the content distribution peer, the claim uses an open-
ended phrase, “comprising” and does not exclude the redirecting step from
including the content distribution peer redirecting the request to an
intermediate device before ultimately sending the request to the neighboring
peer. See Mars Inc. v. H.J. Heinz Co., 377 F.3d 1369, 1376 (Fed. Cir. 2004).
McCanne I teaches an APAR-DNS redirection architecture involving
APAR-DNS servers (e.g., N1*, N2*, and N3*) and content servers (S1, S2,
and S3) co-located with the APAR-DNS servers. FF 1. McCanne I explains
that when a client’s request arrives at server N2*, the S2 address is returned.
However, if content server S2 is overloaded or lacks capacity, N2* will be
informed and will redirect the client to an alternate server or neighboring
peer (e.g., S1 or S3). FF 2. As broadly as claimed, the claimed redirecting
step therefore reads on McCanne I’s “anycast” technique where a content
distribution peer (e.g., server S2) can redirect the request to a neighboring
peer (e.g., S1 or S3) through intermediate devices. See FF 1-2.
Appeal 2009-005967
Application 10/013,677

7
We also note, as we discussed above, the APAR-DNS and content
servers can be content distribution and network peers as recited in claim 1 –
notwithstanding the Examiner’s position in the Advisory Action that the
ISPs are the claimed peers, which is somewhat problematic (Advisory
Action mailed December 28, 2007), and is challenged by Appellants (App.
Br. 4, 7; Reply Br. 4, 5). These servers must have a content distribution
table to detect the closest peering point to direct requests (FF 1-2), and also
detect other peers to send requests to when one server is overloaded (FF 2).
Furthermore, the portion of McCanne I that spans the Appeal Brief at pages
5 and 6 and relates to an alternative explicit redirection embodiment (FF 3).
On the other hand, the Examiner’s (Ans. 2-3) discussion relates to an
alternative incremental deployment of redirection (FF 3).
Lastly, McCanne II teaches a technique that redirects requests to
peers. FF 4. McCanne II explicitly states this process delivers content (id.),
and we therefore are not persuaded that this embodiment fails to redirect a
content request (Reply Br. 10). Additionally, when a node fails, McCanne II
must refer to a table to detect the neighboring node that can service the
request. FF 4. A failed node also lacks capacity, and thus McCanne II
redirects a request because of lack of capacity as recited. Finally, contrary to
Appellants’ assertions (Reply Br. 11), claim 1 does not require the content
peer to redirect the request to a content peer but to “the neighboring peer.”
Moreover, claim 1 recites a content distribution peer and not a content peer.
For the foregoing reasons, Appellants have not shown error in the
obviousness rejection of independent claim 1 based on McCanne I,
McCanne II, and Feldman. We therefore sustain the rejection of claim 1,
and claims 3-12 which fall with claim 1.
Appeal 2009-005967
Application 10/013,677

8
CONCLUSION
The Examiner did not err in rejecting claims 1 and 3-12 under § 103.

ORDER
The Examiner’s decision rejecting claims 1 and 3-12 is affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED

pgc

Anderson Gorecki & Manaras LLP
33 NAGOG PARK
ACTON, MA 01720