Ex Parte Smith et al

Patent Trial and Appeal Board

Apr 23, 2014

10782314 (P.T.A.B. Apr. 23, 2014)

UNITED STATES PATENT AND TRADEMARKOFFICE
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/782,314 02/19/2004 Michael R. Smith CIS0211US 7633
33031 7590 04/23/2014
CAMPBELL STEPHENSON LLP
11401 CENTURY OAKS TERRACE
BLDG. H, SUITE 250
AUSTIN, TX 78758
EXAMINER
JAKOVAC, RYAN J
ART UNIT PAPER NUMBER
2445
MAIL DATE DELIVERY MODE
04/23/2014 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 1
___________ 2
3
BEFORE THE PATENT TRIAL AND APPEAL BOARD 4
___________ 5
6
Ex parte MICHAEL R. SMITH, 7
JEFFREY YM WANG, 8
and ALI GOLSHAN 9
___________ 10
11
Appeal 2011-009334 12
Application 10/782,314 13
Technology Center 2400 14
___________ 15
16
17
Before ANTON W. FETTING, BIBHU R. MOHANTY, and 18
MICHAEL C. ASTORINO, Administrative Patent Judges. 19
FETTING, Administrative Patent Judge. 20
DECISION ON APPEAL 21
22
23
24
Appeal 2011-009334
Application 10/782,314

2

STATEMENT OF THE CASE1 1
Michael R. Smith, Jeffrey YM Wang, and Ali Golshan (Appellants) seek 2
review under 35 U.S.C. § 134 of the Examiner’s final rejection of claims 1-3
3, 5-17, 19-27 and 38-67, the only claims pending in the application on 4
appeal. We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b). 5
The Appellants invented a way of implementing an interface bundle in a 6
virtual network device (Specification para 0001). 7
An understanding of the invention can be derived from a reading of 8
exemplary claim 1, which is reproduced below [bracketed matter and some 9
paragraphing added]. 10
1. A system comprising: 11
a virtual link bundle comprising a plurality of communication 12
links, wherein 13
[1] the plurality of communication links is configured to 14
couple 15
a virtual network device 16
to 17
a first network device 18
external to the virtual network device; 19
[2] a first end of each of the communication links is 20
configured to 21
be coupled to the first network device; 22
[3] a second end of a first one of the communication links 23
is configured to 24

1 Our decision will make reference to the Appellants’ Appeal Brief (“App.
Br.,” filed November 22, 2010) and the Examiner’s Answer (“Ans.,” mailed
February 15, 2011).
Appeal 2011-009334
Application 10/782,314

3

be coupled to a first virtual network device sub-1
unit 2
within the virtual network device; 3
[4] a second end of a second one of the communication 4
links is configured to 5
be coupled to a second virtual network device sub-6
unit 7
within the virtual network device; 8
[5] the first one of the communication links and the 9
second one of the communication links 10
provide redundant connections between 11
the first network device 12
and 13
the virtual network device; 14
[6] the first network device comprises a plurality of ports; 15
[7] each of the ports is configured to 16
communicate packets with a respective client; 17
[8] the first network device is configured to 18
append a header to a packet 19
before sending the packet to the virtual network 20
device 21
via one of the communication links; 22
and 23
[9] the header identifies a one of the ports 24
having received the packet. 25
26
27
28
29
Appeal 2011-009334
Application 10/782,314

4

The Examiner relies upon the following prior art: 1
Beck US 2001/0014097 A1 Aug. 16, 2001
Mankude US 6,735,205 B1 May 11, 2004
Fine US 2005/0083933 A1 Apr. 21, 2005
Stevens, The Protocols, TCP /IP Illustrated, Volume 1, , 600-603, Safari 2
Books Online, Addison Wesley Professional, URL 3
http://proquest.safaribooksonline.com/0201633469/ch17lev1sec3, 4
Print ISBN-10: 0-201-63346-9 (1993). 5
Claims 1-3 and 5-7 stand rejected under 35 U.S.C. § 103(a) as 6
unpatentable over Beck and Stevens. 7
Claims 8-17, 19, 20, 22-27, 38, 40-48, 50-58, and 60-67 stand rejected 8
under 35 U.S.C. § 103(a) as unpatentable over Beck and Fine. 9
Claims 21, 39, 49, and 59 stand rejected under 35 U.S.C. § 103(a) as 10
unpatentable over Beck, Fine, and Mankude. 11
ISSUES 12
The issues of obviousness turn primarily on the breadth of the claim 13
limitations argued. 14
FACTS PERTINENT TO THE ISSUES 15
The following enumerated Findings of Fact (FF) are believed to be 16
supported by a preponderance of the evidence. 17
Facts Related to Claim Construction 18
01. The disclosure contains no lexicographic definition of “link 19
bundle.” 20
21
Appeal 2011-009334
Application 10/782,314

5

Facts Related to the Prior Art 1
Beck 2
02. Beck is directed to making a cluster of processor nodes appear as 3
a single processor node to client applications that operate in 4
conjunction with that cluster. Beck para [0011]. 5
03. Generally speaking, computer systems typically include one or 6
more central processor nodes, referred to simply as “processor 7
nodes” or “nodes.” Each of those processor nodes includes one or 8
more network interface modules, connected to a computer 9
network, for communicating with other processor nodes. Each 10
network interface module has an associated network layer address 11
or IP address to which packets of information are directed. The 12
network layer address allows processor nodes to communicate 13
with one another by sending those packets of information across 14
the computer network. Each packet includes a header that 15
contains the network layer addresses of the originating, or source, 16
processor node and of the destination processor node. Beck para 17
[0001]. 18
04. Groups of processor nodes can be connected in an arrangement 19
referred to as a “cluster.” Generally, processor nodes within a 20
cluster are more tightly coupled than in a general network 21
environment and act in concert with one another. For example, all 22
of the processor nodes within a cluster can share a common file 23
system such that they are able to access the same files. Also, each 24
of the processor nodes within the cluster can use the same security 25
Appeal 2011-009334
Application 10/782,314

6

domain files such that common user names and passwords may be 1
utilized to log on to any of the processor nodes. Beck para [0002]. 2
05. A cluster should appear as a single processor node to clients 3
accessing that cluster. In other words, a cluster should present a 4
common set of software services that can be executed by any of 5
the associated processor nodes. Therefore, regardless of which 6
processor node is accessed by a client, the same services will be 7
provided. In such a manner, processor nodes can be seamlessly 8
added to the cluster to increase the capacity of those services 9
without the cluster looking any different to the client. Beck para 10
[0003]. 11
06. To make a cluster appear to be a single processor node, it should 12
have a single network layer address. Such a network layer address 13
is referred to as a “cluster alias address.” That cluster alias 14
address should not be tied to one specific node within the cluster 15
but rather should be collectively associated with all the processor 16
nodes. To that end, the cluster's network layer address must be 17
accessible regardless of what the current membership of the 18
cluster is. The current membership of a cluster is defined by the 19
nodes that are “up” and capable of running the software services 20
required by any client accessing the cluster. Accordingly, a client 21
accessing the cluster over a network does not need to know which 22
nodes within the cluster are currently up and running in order to 23
access the software services that the cluster provides. Beck para 24
[0004]. 25
Appeal 2011-009334
Application 10/782,314

7

07. Each processor node within the cluster has the ability to distribute 1
received data packets to an appropriate processor node for 2
servicing. When a receiving processor node receives a new data 3
packet that is addressed to the cluster alias address, and which 4
requests establishment of a new connection, the receiving 5
processor node executes an application to select an available 6
processor node in the cluster. That selection is typically 7
performed without regard to the associated port number. Beck 8
paras [0007-0008]. 9
08. When the receiving processor node determines a processor node 10
of the cluster to which a new connection should be established, it 11
retransmits the data packet to the selected processor node over the 12
network. In other words, the data packet’s header is modified to 13
reflect the network layer address of the selected destination 14
processor node, and the data packet is re-broadcast on the network 15
for delivery to that processor node. Beck para [0009]. 16
09. Referring to FIG. 2, a group of processor nodes are shown 17
connected in an arrangement referred to as a “cluster.” A cluster 18
is a collection of processor nodes tightly coupled via a computer 19
network and acting in concert with one another. Processor nodes 20
10a-10c are shown connected together via network interfaces 20a-21
20c and via the computer network 23. The indicated portion of 22
computer network 23 is referred to as a subnet, and in this case 23
“subnet S1” 22. Each of the processor nodes 10a-10c are referred 24
to as Processor nodes A-C and, for illustration purposes, have 25
thirty-two bit network layer (or IP) addresses S1.A, S1.B and 26
Appeal 2011-009334
Application 10/782,314

8

S1.C, respectively. Further, a client processor node 26 is also 1
shown connected to subnet 22 via a network 23 and a network 2
router 25. Beck para [0026]. 3
10. Cluster 24 is associated with a single network layer address such 4
that it appears as a single processor node to a client 26 located 5
outside the cluster, i.e. on the other side of network 23. That 6
network layer address is associated with all the processor nodes 7
10a-10c in the cluster 24 and is referred to as a “cluster alias 8
address.” Using the cluster alias address, data packets are directed 9
to a specific cluster of processor nodes. However, the cluster alias 10
address does not specify the processor node within the cluster to 11
which the data packet should be directed. Therefore, in order to 12
direct incoming data packets to the processor nodes 10a-10c that 13
have established connections with associated source applications, 14
each processor node 10a-10c has the ability to distribute those 15
data packets within the cluster 24. Beck para [0027]. 16
11. Referring to FIG. 4, a flow diagram depicts the establishment of a 17
new connection. When the receiver application running on a 18
processor node 10 within the destination cluster 24 receives the 19
data packet, it first determines whether the packet was sent to the 20
cluster alias address. If the packet was sent to the cluster alias, the 21
application executes a routine to perform cluster-alias specific 22
checks on the packet. Beck para [0034]. 23
12. Each processor node within the cluster associates a value, referred 24
to as the “selection weight” value, with the cluster alias to which it 25
Appeal 2011-009334
Application 10/782,314

9

belongs. The selection weight indicates a processor node's 1
capacity for servicing new connections, in relation to the other 2
processor nodes in the cluster. Each TCP port that a processor 3
node is listening on will be associated with the same selection 4
weight. It should be noted that in an alternative embodiment, the 5
selection weight can be refined such that it is associated with a 6
combination of a processor node’s alias address, Host ID and a 7
TCP port that it is listening on. In such a manner, each TCP port 8
that a processor node is listening on can be associated with a 9
different selection weight. More specifically, the selection 10
weights indicate the number of new connections that a processor 11
node will be issued before a connection is issued to another 12
processor node listening on the same TCP port. Beck paras 13
[0042-0043]. 14
13. A physical subnet is an arrangement of adjacent processor node 15
network layer addresses. Such an arrangement of network layer 16
addresses are differentiated by a network router through the use of 17
a bitmask, referred to as a “subnet mask.” The result of the 18
masking operation is that the destination address is converted into 19
a subnet address identifying the subnet to which the data packet 20
should be directed. Two network layers addresses are in the same 21
subnet if the result of “ANDing” the addresses with their 22
associated subnet mask results in the same subnet address. It is 23
assumed that two nodes sharing the same subnet address can 24
communicate directly without requiring the services of a network 25
router. The whole network layer address is then used to discern 26
Appeal 2011-009334
Application 10/782,314

10

the proper node within the subnet to which the data packet is 1
directed. Beck para [0063]. 2
14. Alternatively, if a cluster alias address is configured in a virtual 3
subnet, i.e. one to which no network layer addresses belong other 4
than cluster alias addresses, then no client processor node will 5
think it is in the same subnet as the cluster alias address. Beck 6
para [0067]. 7
15. Referring to the flow diagram of FIG. 9, the operation of the 8
router address takeover method is shown. When a cluster is 9
configured, each processor node within that cluster establishes a 10
database containing the network layer addresses used by each of 11
the processor nodes in that cluster. Those processor nodes are 12
tightly coupled through the use of a cluster management 13
application. That cluster management application sends a 14
message to the other processor nodes within the cluster when one 15
of those processor nodes crashes. Accordingly, if processor node 16
10a crashes, the cluster management software sends messages to 17
processor nodes 10b and 10c. Processor nodes 10b and 10c 18
arbitrate among themselves to determine which one will acquire 19
the network layer address of processor node 10a. Beck para 20
[0076]. 21
Fine 22
16. Fine is directed to a way a multicast router can prevent loops and 23
enhance stability in a multi-access, multicast network. Fine para 24
[0002]. 25
Appeal 2011-009334
Application 10/782,314

11

17. Even before the DVMRP router has compiled a complete routing 1
table, the router may distribute a multicast stream to other nodes 2
in the network including other DVMRP routers. Upon receipt of a 3
multicast stream, a DVMRP router first performs a reverse path 4
forwarding (RPF) check in which it determines from the DVMRP 5
routing table whether the stream was received on the interface 6
associated with the best route from the multicast source to the 7
router. If the stream is not received on the associated interface, 8
also referred to as the upstream interface, the packet is filtered to 9
prevent a client in a multi-access network from receiving duplicate 10
packets. If the multicast stream is received on the upstream 11
interface, the DVMRP router is configured to propagate the 12
multicast packets downstream to the outer edges of the network. 13
Fine para [0005]. 14
Stevens 15
18. Stevens is directed to a complete and detailed guide to the entire 16
TCP/IP protocol suite. Stevens Overview, 1st paragraph. 17
19. Each TCP segment contains the source and destination port 18
number in the header. Stevens Section 17.3 TCP Header. 19
20
Appeal 2011-009334
Application 10/782,314

12

ANALYSIS 1
Claims 1-3 and 5-7 rejected under 35 U.S.C. § 103(a) as unpatentable over 2
Beck and Stevens 3
As to claim 1, reciting “a virtual link bundle,” we are not persuaded by 4
the Appellants’ argument that the cited references fail to disclose a virtual 5
link bundle. Appellants contend that 6
the Office Action appears to ignore the term “virtual link 7
bundle.” Merely disclosing a plurality of links is not the same 8
as disclosing a virtual link bundle. The term bundle, as applied 9
to links, is a term of art having a specific meaning to those of 10
skill in the art. As described in the Specification, one of the 11
objectives of the claimed invention is to overcome limitations 12
in prior systems that use link bundling techniques . . . . neither 13
Beck nor TCP/IP is directed to virtual link bundles. Instead, 14
Beck is directed to making a cluster of nodes appear as a single 15
node. Beck, Abstract. TCP/IP is simply a general overview of 16
the TCP/IP protocol and is likewise silent in regards to virtual 17
link bundles. 18
App. Br. 10 (citation omitted). As to the issue of the construction of the 19
term “virtual link bundle,” the disclosure has no lexicographic definition, 20
and Appellants provide no objective evidence that the phrase is a term of art. 21
The plain meaning of the phrase is a virtual, that is not real, bundle of links. 22
The Examiner found more than a plurality of links. The Examiner found a 23
plurality of links and processors that appear as a single entity. We adopt the 24
Examiner’s findings from Answer 5, 6, and 21. These findings show that 25
the description of Beck is within the scope of claim 1. Stevens is applied 26
only to show what is inherent in the packets Beck would transfer. 27
As to claim 2, reciting “the first network device is configured to select a 28
communication link of the plurality of communication links on which to 29
Appeal 2011-009334
Application 10/782,314

13

send a particular packet,” we are not persuaded by the Appellants’ argument 1
that Beck 2
refers to intra-cluster communications between nodes of a 3
cluster, not communications over communications links 4
between a network device and a virtual network device. Thus, 5
even if this passage did disclose selecting a communications 6
link . . . . such a communications link would only couple nodes 7
within a cluster and accordingly would not be comparable to 8
the claimed communications links, which couple a network 9
device to a virtual network device. Furthermore, [] while the 10
cited portion of Beck may disclose selecting a particular node, 11
the cited portions fail to disclose multiple communications links 12
connected to the node and a network device configured to select 13
one of the multiple communications links. 14
App. Br. 11. Appellants contend a distinction between inter-device and 15
intra-device communications. But the whole point of both Appellants’ 16
disclosed invention and Beck is to make a plurality of devices appear as a 17
single device. In such a case, intra-virtual device communication is inter-18
physical device communication. We adopt the Examiner’s findings from 19
Answer 6 and 22. These findings show that the description of Beck is within 20
the scope of claim 2. 21
As to claim 7, reciting “the communication links are configured to be 22
managed as a single link”, we are not persuaded by the Appellants’ 23
argument that the 24
Office Action states that Beck's disclosure of using cluster 25
aliases to make a cluster appear as a single node discloses this 26
feature. . . . Even if Beck's cluster does appear to be a single 27
node, that says nothing about the number of links connected to 28
the cluster or the configuration of those links. 29
App. Br. 11. Appellants’ argument is not commensurate with the scope 30
of the claim. Claim 7 does not recite a number of links connected to the 31
Appeal 2011-009334
Application 10/782,314

14

cluster or the configuration. Claim 7 instead recites an aspiration rather than 1
a function, and is accordingly deserving of no patentable weight. We adopt 2
the Examiner’s findings from Answer 7 and 23. These findings show that 3
the description of Beck is within the scope of claim 7. 4
Claims 8-17, 19, 20, 22-27, 38, 40-48, 50-58, and 60-67 rejected under 35 5
U.S.C. § 103(a) as unpatentable over Beck and Fine 6
As to claim 8, reciting “wherein the first interface is identified by a first 7
logical identifier, a second interface is identified by the first logical 8
identifier,” we are not persuaded by the Appellants’ argument that 9
Beck’s processor nodes, which the Office Action appears to 10
equate with the claimed interfaces, is associated with a unique 11
address. Therefore, Beck fails to disclose a first and second 12
interface that are both identified by the same logical identifier 13
App. Br. 12. The Examiner found a plurality of links and processors that 14
appear as a single entity. To accomplish this, Beck describes an alias 15
address common to all devices under the same virtual device umbrella. 16
Appellants’ arguments regarding a bundle are similar to the arguments in 17
support of claim 1. We adopt the Examiner’s findings from Answer 8, 9, 18
and 23. These findings show that the description of Beck is within the scope 19
of claim 8. 20
As to claim 17, reciting “the first virtual network device sub-unit is 21
configured to learn that a source address of a second packet is behind the 22
first interface, in response to receiving the second packet via the virtual 23
network device link,” we are not persuaded by the Appellants’ argument that 24
the packets referred to . . . are packets addressed to the cluster 25
alias. This means that the packets referred to are received from 26
Appeal 2011-009334
Application 10/782,314

15

an external router, and not from another processor node within 1
the cluster. Thus, the packets are not received via an intra-2
cluster communications link. 3
App. Br. 13. The Examiner found that inside the virtual device, packet 4
addresses are decoded for routing and routed accordingly. FF 13-14. We 5
adopt the Examiner’s findings from Answer 11 and 23. These findings show 6
that the description of Beck is within the scope of claim 17. 7
As to claim 23, reciting “the first virtual network device sub-unit is 8
configured to lookup a destination address of a packet in a lookup table, and 9
if the lookup table returns the first logical identifier, the first virtual network 10
device subunit is configured to prioritize sending the packet via the first 11
interface over sending the packet via the second interface,” we are not 12
persuaded by the Appellants’ argument that Beck discloses 13
that when first processor node having a first address fails, a 14
second processor node having a second address and a third 15
processor node having a third address decide which (the second 16
or third) processor node will acquire the address of the failed 17
processor node. [] This is not comparable to claim 23. This is a 18
selection of which processor node will be used to send a packet, 19
where the processor nodes have distinct (non-identical) 20
identifiers. Furthermore, once the selection of which processor 21
node will adopt the failed processor node's address is made, the 22
packets are sent by that processor node. That is, no selection 23
between interfaces is made in Beck once the failover completes. 24
On the other hand, claim 23 recites features of a system 25
configured to select between sending a packet over a first 26
interface and sending the packet over a second interface where 27
both the interfaces are identified by the same identifier. 28
App. Br. 14 (citation omitted). The Examiner found that each node in 29
the cluster is assigned a selection weights which indicates a processor node's 30
capacity for servicing new connections, in relation to the other processor 31
Appeal 2011-009334
Application 10/782,314

16

nodes in the cluster. The nodes use this information to prioritize which node 1
will service the packet. FF 12 and 15. We adopt the Examiner’s findings 2
from Answer 13 and 24. These findings show that the description of Beck is 3
within the scope of claim 23. 4
Claims 21, 39, 49, and 59 rejected under 35 U.S.C. § 103(a) as unpatentable 5
over Beck, Fine, and Mankude 6
Appellants rely on parent claim arguments in support of these claims. 7
CONCLUSIONS OF LAW 8
The rejection of claims 1-3 and 5-7 under 35 U.S.C. § 103(a) as 9
unpatentable over Beck and Stevens is proper. 10
The rejection of claims 8-17, 19, 20, 22-27, 38, 40-48, 50-58, and 60-67 11
under 35 U.S.C. § 103(a) as unpatentable over Beck and Fine is proper. 12
The rejection of claims 21, 39, 49, and 59 under 35 U.S.C. § 103(a) as 13
unpatentable over Beck, Fine, and Mankude is proper. 14
DECISION 15
The rejection of claims 1-3, 5-17, 19-27 and 38-67 is affirmed. 16
No time period for taking any subsequent action in connection with this 17
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 18
§ 1.136(a)(1)(iv) (2011). 19
20
AFFIRMED 21
rvb 22