Ex Parte Xu et al

Board of Patent Appeals and Interferences

Sep 27, 2010

10346067 (B.P.A.I. Sep. 27, 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/346,067 01/17/2003 Zhichen Xu 100202080-1 2719
7590 09/28/2010
HEWLETT-PACKARD COMPANY
Intellectual Property Administration
P.O. Box 272400
Fort Collins, CO 80527-2400
EXAMINER
CHRISTENSEN, SCOTT B
ART UNIT PAPER NUMBER
2444
MAIL DATE DELIVERY MODE
09/28/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 ZHICHEN XU and ZHENG ZHANG
_____________

Appeal 2009-005764
Application 10/346,067
Technology Center 2400
______________

Before JOHN C. MARTIN, MARC S. HOFF, and THOMAS S. HAHN,
Administrative Patent Judges.

MARTIN, Administrative Patent Judge.

DECISION ON APPEAL1

1 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-005764
Application 10/346,067

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

A. Appellants’ invention
Appellants’ invention relates to peer-to peer (P2P) systems, which
represent a class of networks that utilize distributed resources and perform
critical functions in a decentralized manner (Specification [0007]), and more
particularly relates to methods and an apparatus for mapping peers in a peer-
to-peer network to an overlay network (id. at [0012-13]).2 The overlay
network can take the form of an expressway overlay network, which
provides a mechanism for a peer to find the most direct route, i.e., an
expressway, to a destination in the smallest number of Internet hops (id. at
[0029]). The expressway overlay network may comprise a hierarchal layer
of zones (id. at [0030]).
Figure 1 is reproduced below.

2 As in the Brief, references herein to Appellants’ Specification are to Patent
Application Publication 2004/0143666 A1 rather than to the Application as
filed.
Appeal 2009-005764
Application 10/346,067

3

Figure 1 illustrates an embodiment of a peer-to-peer network (id. at
[0036]). Network 100 includes nodes A-H that are physically distributed in
the network 100 as shown (id.). The “network coordinates” of these nodes
reflect their physical positions in the network (id. at [0035]), as obtained, for
example, from global positioning system (GPS) satellites (id. at [0070]).
Alternatively, the network coordinates can take the form of a landmark
vector representing the distance (e.g., Euclidean distance) to a set of
landmark peers in the P2P network (id.). Each of nodes A-H in physical
network 100 can execute a peer-to-peer application or an expressway routing
application (id. at [0036]).
Appeal 2009-005764
Application 10/346,067

4
Network 100' in Figure 1 represents an expressway overlay network
(id.). The eight zones 110a' and 110b' are the fundamental zones of the
expressway overlay network, and each of the two higher-order zones 120a'
and 120b' consists of a group of four fundamental zones 110a' or 110b' (id.
at [0037]). If the expressway overlay network is a Cartesian space, “the
expressway routing module may be configured to map the network
coordinate of a selected node into Cartesian space” and “[t]he Cartesian
coordinate of the selected node falls within a zone.” (Id. at [0034].) If the
owner of the zone does not coincide with selected node because of the
ordering of the expressway overlay network,
[t]he expressway routing module may then store a data tuple of
the selected node compris[ed] of the zone, network coordinate,
and the address of the selected node in the node that owns the
zone, i.e., a data triple. In this manner, a selected node may
publish its position to form coordinate maps.
(Id. (emphasis added).)
As explained in more detail below in the discussion of the rejection of
claims 11-25, a routing module can use a hash function to convert a network
coordinate into a target coordinate in a logical space.

B. The claims
The independent claims before us are claims 1, 11, 16, and 22, of
which claim 1 reads as follows:
1. A method of mapping peers in a peer-to-peer network
to an overlay network[,] said method comprising:
determining network coordinates for a selected peer;
Appeal 2009-005764
Application 10/346,067

5
determining logical coordinates in said overlay network
based on said network coordinates;
determining a zone based on said logical coordinates; and
storing an object comprising said network coordinates, a
network address of said selected peer, and said zone in a peer
owning said zone, whereby associated information is stored in
said peer that has said network coordinates and using said
network coordinates as a key.
Claims App. (Br. 13).

C. The reference
The Examiner’s rejections are based on the following reference:
Lu et al. (“Lu”) US 6,980,524 B1 Dec. 27, 2005

D. The rejections
Claims 1-9 and 11-25 stand rejected under 35 U.S.C. § 102(e) for
anticipation by Lu. Final Action 2, para. 4.
Claim 10 stands rejected under 35 U.S.C. § 103(a) for obviousness
over Lu. Id. at 8, para. 6.

THE ISSUES
Regarding the rejection of claims 1-10, Appellants argue, inter alia,
that Lu fails to satisfy the requirement of claim 1 for “storing an object
comprising said network coordinates, a network address of said selected
Appeal 2009-005764
Application 10/346,067

6
peer, and said zone in a peer owning said zone.”3 Regarding the rejection of
independent claims 11, 16, and 22, Appellants argue that Lu fails to disclose
hashing, which is required by each of these claims.

ANALYSIS
A. The rejection of claims 1-10
Lu discloses methods and apparatus for determining routing in a
mobile ad hoc network. Lu, title.4
Lu’s Figure 1 is reproduced below.

3 See Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential)
(“If an appellant fails to present arguments on a particular issue — or, more
broadly, on a particular rejection — the Board will not, as a general matter,
unilaterally review those uncontested aspects of the rejection.”). Designated
precedential at
http://www.uspto.gov/ip/boards/bpai/decisions/prec/index.jsp.
4 In quotations herein from Lu, bolding of the reference numerals is omitted.
Appeal 2009-005764
Application 10/346,067

7

Figure 1 is a high-level diagram of virtual connections between zones
in a mobile ad hoc network (Lu, col. 6, ll. 17-18). Network 100 includes
zones 110, labeled 1-9 (col. 8, ll. 13-16), of which zone 1 has orthogonally
adjacent zones 2, 3, 4, and 5. As will appear from the following discussion
of Figure 2, the heavy lines in Figure 1 represent existing communications
links between the zones.
Figure 2 is reproduced below.
Appeal 2009-005764
Application 10/346,067

8

Figure 2 illustrates a zone 110' within a network 100' (col. 8, ll. 31-32)
and more particularly illustrates zone 1 of Figure 1. Node “b” (202) in zone
1 has direct physical (e.g., wireless) communication links 204 with nodes
“a” and “e” in zone 1 (col. 8, ll. 33-37). Node “e” also has a direct physical
communications link with node “h” (206) in zone 2, thereby making a node
“e” a gateway node from zone 1 to zone 2 (col. 8, ll. 37-42). Node “f” in
zone 1 is another gateway node from zone 1 to zone 2.
Lu’s routing method employs two levels of topology: node level
topology and zone level topology (col. 8, ll. 43-44). A node uses the node
level topology to route a packet within its own zone and uses the zone level
topology to route a packet to another zone (col. 8, ll. 57-60). Lu accordingly
discloses processes for generating intra-zone and inter-zone routing tables
480 and 490 (Fig. 4), respectively (col. 10, ll. 54-56).
Appeal 2009-005764
Application 10/346,067

9
Lu employs three types of processes: (i) self state determination;
(ii) network state determination; and (iii) data transmission (col. 9, ll. 25-28).
The “self state determination processes” 410 (Fig. 4) can include a
geographic position determination process 412 and a geographic position-to-
zone mapping process 414 (col. 9, ll. 37-39). The geographic position
determination process 412 can be performed by a location determination unit
370 (Fig. 3), such as a GPS unit, to generate a current position 454 (col. 9, ll.
40-43). Next, “[t]he geographic position to zone mapping process [414] can
. . . use the current position 454, as well as a geographic location range to
zone map 452, to determine the zone 110, 456 of the network 100 in which
the node 202 is currently located” (col. 9, ll. 43-47).
Appellants argue, inter alia, the following language from the last step
of claim 1: “storing an object comprising said network coordinates, a
network address of said selected peer, and said zone in a peer owning said
zone.” (Br. 8.) As noted in Appellants’ Specification, the network address
for a peer (i.e., node) can be, for example, an IP address ([0085]).
Appellants question the Examiner’s finding that the recited “network address
of said selected peer” reads on the identification, during Lu’s routing
process, of the “destination zone” that contains the “destination node,” on
which the Examiner reads the recited “selected peer.” Specifically, the
Examiner reads the recited “object” on Lu’s inter-zone routing table 490
(Fig. 4) and more particularly on the examples of that table given in Lu’s
Figures 18 and 19, of which Figure 18 is reproduced below.
Appeal 2009-005764
Application 10/346,067

10

Figure 18 is an exemplary data structure 490' for inter-zone routing
table 490 (Fig. 4) (col. 17, ll. 45-46). This table includes a field 1810 for
identifying the source node and associated records 1820 that include: a field
1822 identifying the available destination zones, a field 1824 identifying the
available next zones, and a field 1826 identifying the available next nodes
(col. 17, ll. 46-52).
Figure 19 is reproduced below.
Appeal 2009-005764
Application 10/346,067

11

Figure 19 is an example of an inter-zone routing table 490" for node
“a” in zone 1, as indicated by field 1810' (col. 17, ll. 53-54). The records in
this table reflect the nodes, zones, and communications links depicted in
Figures 1 and 2 (col. 17, l. 55). For example, the sixth of the records 1820'
indicates that if the “destination zone” (first column) is zone 6, the “next
zone” (second column) is zone 2 and the “next node” (third column) is
node “b.” The Examiner has found that “the network address of said
selected peer is identified by [the] next zone[,] which is the network address
of that subnet[;] also read Col[.] 11-Lines[ ]35-40.” May 21, 2007, Office
Action 16-17. In response to Appellants’ argument that “a network address
of a selected zone cannot be equivalent to the claimed network address of a
Appeal 2009-005764
Application 10/346,067

12
selected peer or node” (Sept. 18, 2007, “Response Under 37 C.F.R. § 1.111”
at 11), the Examiner explained that “[f]or inter-zone communications, the
communication is routed based on the zone that the node is located in,
essentially making the zone’s address and the node’s address the same
address.” Final Action 10. Because claim 1 recites storing the “network
address of said selected peer [i.e., node]” along with the “zone” that contains
the selected peer, we agree with Appellants (Br. 8-9) that the recited
“network address of said selected peer” must be more specific than
identifying the zone in which the selected peer resides. We therefore agree
that the Examiner erred in reading the stored “network address of said
selected peer” as well as the stored “zone” on Lu’s “destination zone,”
which merely identifies the zone that contains the “destination node.”
For the foregoing reason, we will not sustain the rejection of claim 1
and its dependent claims 2-9 for anticipation by Lu. For the same reason,
and because the Examiner does not alternatively rely on obviousness to
remedy the above deficiency, we will not sustain the rejection of dependent
claim 10 for obviousness over Lu.

B. The rejection of claims 11-25
Each of independent claims 11, 16, and 22 recites “hashing.” Claim
11, which is representative, reads as follows:
11. An apparatus for mapping peers in a peer-to-peer
network to an overlay network, said apparatus comprising:
means for determining a network coordinate of a peer;
Appeal 2009-005764
Application 10/346,067

13
means for hashing said network coordinate into a target
coordinate in the logical space of said overly network; and
means for determining a target zone based on said target
coordinate.
Claim 7, which depends on claim 1 through claim 5, recites “hashing”
and a “hash function”:
7. The method according to claim 5, further comprising:
hashing said plurality of landmark vectors into logical
coordinate space with a hash function configured to maintain
physical relationships of said plurality of landmark vectors.
Hashing is discussed in Appellants’ Specification in connection with
Figure 8B, reproduced below.
Appeal 2009-005764
Application 10/346,067

14

Figure 8B illustrates an exemplary flow diagram for the expressway
routing module 230 (Fig. 2) and routing module 450 (Fig. 4) (Specification
[0094]). In step 810', the network coordinates of a peer can be determined
with a GPS system or by using landmark vectors (id. at [0095]). In step
815', the routing module 450 can be configured to determine (or map) the
network coordinates, pt, to Cartesian coordinates, pt', of the underlying P2P
system (id. at [0096]). Routing module 450 can use a hash function to map
Appeal 2009-005764
Application 10/346,067

15
the dimensionality of the landmark vector to the dimension of the
expressway overlay network (id.). For example, the hash function can take
the form pt' = h(pt, dp, dz, z), where dp is the dimension of pt; z is the region
in which pt’s proximity information is about to be stored; dz is the
dimension of region z; and pt' is a position in region z (id.). The Examiner
has found that paragraph 0096 “cites a specific hashing function, but also
appears to correlate hashing to mere mapping.”5 Final Action 11.
Lu, as noted by Appellants (Br. 9), makes no mention of a hash or a
hashing function. The Examiner (Final Action 5) reads the recited
“hashing” function on Lu’s disclosure that “as shown in block 620, the
current geographic position of the node is converted to a zone of the network
based on a mapping function or table” (col. 13, l. 66–col. 14, l. 2). Lu does
not provide any details of this mapping function or table. As support for
interpreting the claimed “hashing” function as broad enough to read on this
conversion operation, the Examiner (Final Action 11) relies on the following
dictionary definition:
hash2 vb. To be mapped to a numerical value by a transformation
known as a hashing function. Hashing is used to convert an
identifier or key, meaningful to a user, into a value for the location
of the corresponding data in a structure, such as a table. For
example, given the key MOUSE and a hashing function that
added up the ASCII values of the characters, divided by the total
127, and took the remainder, MOUSE would hash to 12 and the

5 The Examiner’s citation to this paragraph is to page 26, lines 8-14 of the
Application as filed.
Appeal 2009-005764
Application 10/346,067

16
data identified by MOUSE would be found among the items in
entry 12 in the table.
MICROSOFT COMPUTER DICTIONARY (5th ed., 2002) 247-48.6 The same
dictionary also provides the following definition of “hashing algorithm”:
hashing algorithm n. A formula used to generate hash values
and digital signatures. Also called: hash function.
Id. at 248.
In response to Appellants’ argument that the above definition of
“hash” requires mapping to a numerical value “by a transformation known
as a hashing function” (Br. 9) and that the “mere mapping of data in Lu”
therefore cannot be characterized as “hashing” (id. at 10), the Examiner
explains that
to hash is to be mapped to a numerical value by a formula (a
transformation known as a hashing function). . . .
When a value is mapped to another value, the two values
are made equal to each other. For example, y=x would simply be
mapping the values from the variable x to the variable y. f(x)=x
would be doing the same, but is written in a different form. . . . As
x=y and f(x)=x (which are both functions that simply map the
value of x to either y or f(x), respectively) are both formulas, they
meet the definition of hashing function (it is noted that this
appears in the Microsoft Computer Dictionary 5th Edition on page
248 under the definition for “hashing algorithm,” which is also
called “hash function” according to the definition).
(Answer 13-14.) We agree with Appellants (Reply Br. 6) that the Examiner
is improperly interpreting the phrase “[t]o be mapped to a numerical value
by a transformation known as a hashing function” in the above dictionary
Appeal 2009-005764
Application 10/346,067

17
definition of “hash” to be defining hashing as the use of any mathematical
function to map to a numerical value. Instead, the definition defines hashing
as a particular way of mapping to a numerical value, namely, as using a
transformation known as a hashing function to map to a numerical value.
Because Lu does not describe the mapping function as a hash function or
provide any details suggesting that the mapping process employs a hash
function, we agree with Appellants that the Examiner has failed to
demonstrate anticipation of the “hashing” claims. Consequently, we will not
sustain the anticipation rejection of independent claims 11, 16, and 22 and
their dependent claims 12-15, 17-21, and 23-25. The above reasoning also
constitutes a second reason for not sustaining the rejection of claim 7, which
depends indirectly on claim 1.

DECISION
We will not sustain the rejection of claims 1-9 and 11-25 under 35
U.S.C. § 102(e) or the rejection of claim 10 under 35 U.S.C. § 103(a) for
obviousness over Lu.
The Examiner’s decision that claims 1-25 are unpatentable is
reversed.
REVERSED

6 Initially cited in the February 8, 2007, Office Action at page 18.
Appeal 2009-005764
Application 10/346,067

18

babc

HEWLETT-PACKARD COMPANY
Intellectual Property Administration
P.O. Box 272400
Fort Collins, CO 80527-2400