`By: Michael T. Rosato (mrosato@wsgr.com)
`
`Andrew S. Brown (asbrown@wsgr.com)
`Eric C. Arnell (earnell@wsgr.com)
`WILSON SONSINI GOODRICH & ROSATI
`701 Fifth Avenue, Suite 5100
`Seattle, WA 98104-7036
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________________
`
`
`
`BUNGIE, INC.,
`Petitioner,
`
`v.
`
`ACCELERATION BAY, LLC,
`Patent Owner.
`
`_____________________________
`
`Patent No. 6,829,634
`Case No. IPR2017-01601
`_____________________________
`
`
`
`PETITION FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 6,829,634
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`Introduction .................................................................................................. 1
`
`Page
`
`A.
`
`Brief Overview of the ’634 Patent....................................................... 1
`
`B.
`
`C.
`
`Brief Overview of the Prosecution History ......................................... 6
`
`Brief Overview of the Scope and Content of the Prior Art .................. 6
`
`i.
`
`Background computer networking concepts and
`terminology............................................................................... 7
`
`ii.
`
`Techniques for adding a node to a network ............................. 15
`
`D.
`
`Brief Overview of the Level of Skill in the Art ................................. 24
`
`II. Mandatory Notices under 37 C.F.R. § 42.8 ................................................. 24
`
`III. Grounds for Standing .................................................................................. 28
`
`IV. Statement of the Precise Relief Requested for each Claim Challenged ....... 29
`
`V.
`
`Claim Construction ..................................................................................... 32
`
`VI. Detailed Explanation Of Grounds For Unpatentability ................................ 32
`
`A.
`
`B.
`
`C.
`
`The ’634 Patent Claims 19-24 are Obvious over Gilbert and
`Francis. ............................................................................................. 33
`
`Independent Claim 19 ....................................................................... 40
`
`Dependent Claim 20 ......................................................................... 61
`
`D. Dependent Claim 21 ......................................................................... 61
`
`E.
`
`F.
`
`Dependent Claim 22 ......................................................................... 62
`
`Dependent Claim 23 ......................................................................... 63
`
`G. Dependent Claim 24 ......................................................................... 65
`
`VII. Conclusion .................................................................................................. 67
`
`-i-
`
`
`
`
`VIII. Certificate of Compliance ........................................................................... 68
`
`IX. Payment of Fees under 37 C.F.R. §§ 42.15(a) and 42.103........................... 69
`
`X. Appendix – List of Exhibits ........................................................................ 70
`
`
`
`
`
`-ii-
`
`
`
`
`
`I.
`
`INTRODUCTION
`
`Pursuant to the provisions of 35 U.S.C. § 311 and § 6 of the Leahy-Smith
`
`America Invents Act (“AIA”), and to 37 C.F.R. Part 42, Bungie, Inc., (“Bungie” or
`
`“Petitioner”) hereby requests review of United States Patent No. 6,829,634 to Fred
`
`B. Holt et al. (hereinafter “the ’634 patent,” EX1001) that issued on December 7,
`
`2004, and is currently assigned to Acceleration Bay, LLC (“Patent Owner”). This
`
`Petition demonstrates that, by a preponderance of the evidence, that it is more
`
`likely than not that claims 19-24 of the ’634 patent are unpatentable for failing to
`
`distinguish over prior art. Thus, claims 19-24 of the ’634 patent (“subject claims”)
`
`should be found unpatentable and canceled.
`
`A. Brief Overview of the ’634 Patent
`
`The ’634 patent is entitled “BROADCASTING NETWORK.” In a general
`
`sense, the subject claims of the ’634 patent are directed to a method for adding a
`
`participant to a network of participants by “establishing a connection between the
`
`participant and … neighbor participants.” See, e.g., EX1001, claim 19; EX10031
`
`¶9.
`
`Claim 19’s method includes five steps for adding a participant: (1) locating a
`
`portal computer; (2) requesting that portal computer provide an indication of
`
`neighbor participants to which the participant can be connected; (3) receiving the
`
`
`1 Declaration of Dr. Nicholas Bambos, Ph.D.
`
`1
`
`
`
`
`
`indications of those neighbor participants; (4) dropping the connection between the
`
`indicated neighboring participants (this is required in order to meet the limitation
`
`discussed below that the network is m-regular); and (5) establishing a connection
`
`between the participant and each of the indicated neighbor participants. EX1003
`
`¶10.
`
`Claim 19 also includes elements about the graph topology: connections are
`
`not established between the portal computer on the one hand and the participant or
`
`the neighbor participants on the other; “the network is m-regular and m-connected,
`
`where m is the number of neighbor participants of each participant;” and “the
`
`number of participants is at least two greater than m thus resulting in a non-
`
`complete graph.” EX1003 ¶11 (citing EX1001 at 30:30-40).
`
`The elements added by the dependent subject claims concern certain aspects
`
`of the method: participants are computer processes executing on different
`
`computer systems (claims 20-21); after the node has joined, communications occur
`
`by a participant receiving data from a neighbor participant and transmitting that
`
`data to other neighbor participants (claim 22); connections to the joining
`
`participant are established by disconnecting nodes from one another in favor of
`
`establishing connections to the joining participant (claim 23); and communications
`
`use the TCP/IP protocol (claim 24). EX1003 ¶12.
`
`-2-
`
`
`
`
`
`Three central aspects of the subject claims are discussed below: (1) m-
`
`regular graphs; (2) nodes like those the ’634 patent refers to as “portal computers;”
`
`and (3) disconnecting nodes from one another in favor of connections to a joining
`
`node. See also id. ¶13.
`
`M-regular graphs. A large portion of the specification concerns m-regular
`
`and m-connected graphs. M-regular refers to the number of connections per node:
`
`“A graph in which each node is connected to four other nodes is referred to as a 4-
`
`regular graph.” EX1001 at 4:64-65. M-connected refers to the number of node
`
`failures it would take for a network to become divided into two parts: “it would
`
`take a failure of four computers to divide the graph into disjoint sub-graphs, that is
`
`two separate broadcast channels. This property is referred to as being 4-
`
`connected.” Id. at 5:1-5. See EX1003 ¶14.
`
`Portal computers. When the specification describes portal computers, for
`
`the most part, the “description assumes that the broadcast channel is in the large
`
`regime,” meaning “five or more computers are connected,” and there is “a 4-
`
`regular graph.” EX1001 at 5:52-56. See also id. at 15:20-24 (“In the embodiment
`
`described above [discussing portal computers], each fully connected computer has
`
`four internal connections. The broadcast technique can be used with ... any even
`
`number of internal connections.”). Portal computers are nodes that are a point of
`
`contact for another node locating and joining the network. E.g., EX1001 at 5:37-
`
`-3-
`
`
`
`
`
`39 (“Each computer is aware of one or more ‘portal computers’ through which that
`
`computer may locate the broadcast channel.”); 12:33-35 (“Each computer that can
`
`connect to the broadcast channel has a list of one or more portal computers through
`
`which it can connect to the broadcast channel.”). The portal computer is
`
`responsible for directing the identification of other nodes “to be the seeking
`
`computer’s neighbors.” Id. at 5:67-6:3 (4-regular embodiment; the “portal
`
`computer then directs the identifying of four computers (i.e., to be the seeking
`
`computer’s neighbors) to which the seeking computer is to connect.”). “The portal
`
`computer may also enforce security and not allow an unauthorized user to connect
`
`to the broadcast channel.” Id. at 29:7-9. See EX1003 ¶15.
`
`Disconnecting nodes from one another in favor of connections to a joining
`
`node. Once a pair of neighbor participants is indicated, the indicated participants
`
`break their connection to one another in favor of connecting to the joining
`
`computer. EX1001 at 14:10-13; EX1003 at ¶16. Figures 3A and 3B depict this
`
`step. EX1001 at Figs. 3-4. In these figures, nodes E and B go from having a
`
`connection between them to having no connection between them and each having a
`
`connection to added node Z.
`
`-4-
`
`
`
`
`
`
`
`See EX1003 ¶17.
`
`As described below and in the accompanying testimony from Dr. Bambos,
`
`the method for establishing connections among network participants claimed by
`
`the ’634 patent subject claims was well known and would have been obvious to
`
`those in the field. Id. at ¶18. This includes each of the key aspects noted above,
`
`(1) m-regular graphs; (2) “portal computers;” and (3) disconnecting nodes from
`
`one another in favor of connections to a joining node. See id. ¶¶13,18. For
`
`example, m-regular topologies were well known in the art. See id. ¶¶40-42. The
`
`concept of “portal computers” was also well known in the art, such as in systems
`
`making use of designated nodes such as “rendezvous points” or “cores” or
`
`“network managers” to facilitate joining a network. See id. ¶¶57-66. Likewise,
`
`disconnecting nodes from one another in favor of connections to a joining node
`
`was well known, and indeed is necessitated by certain well known network
`
`topologies, including m-regular topologies. See id. ¶¶67-69, 71-74.
`
`-5-
`
`
`
`
`
`B.
`
`Brief Overview of the Prosecution History
`
`Application No. 09/629,576 was filed on July 31, 2000 and issued on
`
`December 7, 2004 as U.S. Patent No. 6,829,634. That examination included only
`
`one rejection, mailed on February 4, 2004. EX1002 at 0159-167. The examiner’s
`
`(non-final) rejection of the then-pending claims was for prior art grounds. In
`
`response, on May 7, 2004 the applicant amended its claims, and argued (among
`
`other things) that the prior art identified by the examiner did not anticipate the
`
`claims as amended. EX1002 at 0246-260. In its remarks, the applicant did not
`
`discuss the “computer readable medium” aspect of the preamble of claim 19 [then
`
`pending claim 44], indicating that this claim is instead directed to “a ‘non-routing
`
`table based’ method for routing information.” Id. at 0258.
`
`Neither of the references discussed in the ground below (the Gilbert and
`
`Francis references) were cited or considered during the prosecution of the ’634
`
`patent.
`
`C. Brief Overview of the Scope and Content of the Prior Art
`
`As explained in detail in the corresponding Declaration of Dr. Nicholas
`
`Bambos (Exhibit 1003) and addressed in further detail below (Section VI), the
`
`involved claims would not have been considered new or non-obvious to a person
`
`of ordinary skill in the art at the relevant time. EX1003 ¶¶97-167. Specifically,
`
`the claimed methods are “directed to employing basic and well-known concepts
`
`-6-
`
`
`
`
`
`and procedures for adding a node to an existing computer network.” Id. ¶34. See
`
`also Section I.A (discussing overview of the ’634 patent).
`
`i. Background computer networking concepts and terminology
`
`Those skilled in the art routinely discuss concepts of computer networks
`
`using terminology associated with graph theory. See id. at ¶36. In graph theory,
`
`computer networks and their topologies are represented by graphs that depict or
`
`model relationships or connections between nodes. See id.; EX1001 at 4:49-52;
`
`EX1022 at 3:67-4:8. In a graph, a node represents a participant (e.g., computer,
`
`router, processor), and an edge (line) between two nodes represents a connection
`
`between those nodes. EX1003 ¶¶37-38; EX1001 at 4:49-52; EX1022 at 3:67-4:8.
`
`Connections between nodes can be physical (e.g., a point-to-point physical link
`
`between nodes, such as an Ethernet cable) or logical (a point-to-point data link
`
`between nodes—underlying physical interconnections are immaterial). EX1003
`
`¶39; see also EX1023 at 52-54; EX1024 at 10-11.
`
`Neighbors are nodes that are directly connected to each other. EX1003
`
`¶¶37-38; EX1001 at 4:49-52; EX1022 at 4:64-67. The degree of a node refers to
`
`the number of neighbors it has. EX1003 ¶40; see also EX1025 at 118; EX1023 at
`
`4:10-12. A regular graph is one in which each node has the same degree. EX1003
`
`¶40; see also EX1025 at 118; EX1026 at 11 ¶2. An m-regular graph is one in
`
`which each node has degree m. EX1003 at ¶40; see also EX1001 at 4:64-5:1;
`
`-7-
`
`
`
`EX1025 at 118. For example, the figure drawn below shows a 4- regular graph in
`
`which each of the six nodes is connected to exactly four other nodes:
`
`
`
`A network topology refers to the specific arrangement of nodes in a
`
`
`
`computer network. See EX1003 ¶¶36, 41-45. The above-illustrated network is an
`
`example of a regular mesh topology. EX1003 ¶¶40-41; see also EX1026 at 11 ¶1.
`
`Other regular network topologies include, ring, torus, Manhattan street network,
`
`and hypercube (respectively illustrated below). EX1003 ¶41; see also, EX1022 at
`
`4:53-57, 6:4-21, Fig. 1C (ring), Fig. 2D (hypercube); EX1027 at 324 ¶5, Fig. 1
`
`(torus); EX1028 at 510 ¶2, Fig. 1 (Manhattan street network).
`
`-8-
`
`
`
`
`
`
`
`
`
`Torus
`EX1027 Fig. 1
`
`Ring
`EX1022 Fig. 1C
`
`
`
`
`
`
`
`Hypercube
`EX1022 Fig. 2D
`
`Manhattan Street Network
`EX1028 Fig. 1
`
`Each of the above are also examples of incomplete networks (i.e., each node
`
`is connected to less than all other nodes). EX1003 ¶42. Other networks may have
`
`a complete (i.e., each node is connected to all other nodes) topology. Id.; see also
`
`EX1026 at 11 ¶1, Fig. 6 (illustrating a 6-regular incomplete mesh); EX1022 at 5:4-
`
`7, Fig. 1F (illustrating below a 7-regular complete mesh). In a complete topology,
`
`-9-
`
`
`
`a node that has a direct connection to every other node is sometimes referred to as
`
`a fully connected node. EX1003 ¶42.
`
`
`
`
`
`EX1022 Fig. 1F.
`
`Network topologies may also be non-regular (i.e., nodes have different
`
`degrees). EX1003 ¶50; see also EX1026 at 11 ¶2. Non-regular topologies include
`
`tree and non-regular mesh (respectively illustrated below). EX1003 ¶43; see also
`
`EX1022 at 4:61-62, Fig. 1D (tree); EX1026 at 11 ¶1, Fig 2 (mesh).
`
`Tree EX1022 Fig. 1D
`
`
`
`Mesh EX1026 Fig. 2.
`
`
`
`-10-
`
`
`
`
`
`As Dr. Bambos explains, “[a]ll network topologies share a basic purpose, to
`
`facilitate the distribution of data among each of the participants of a network.”
`
`EX1003 ¶44. And, “[g]iven their common purpose, concepts and protocols
`
`developed for or applicable to one topology are often applicable or adaptable for
`
`use in another topology.” EX1003 ¶45.
`
`Routing algorithms describe the manner in which data propagates through a
`
`network. EX1003 ¶46; see also EX1030 at abstract; EX1023 generally. Routing
`
`algorithms typically fall within three categories: unicast—one-to-one delivery of
`
`data, broadcast—one-to-all delivery of data, and multicast—one-to-some delivery
`
`of data. EX1003 ¶46; see also EX1023 at 51. These routing algorithms use certain
`
`protocols that define rules for network communications. EX1003 ¶46. TCP/IP
`
`(Transmission Control Protocol/Internet Protocol) is one such well-known
`
`protocol, and is a primary protocol used for internet communications. Id.
`
`“A person of ordinary skill in the art,” Dr. Bambos explains, “would know
`
`of many ways to implement each of these types of routing algorithms, including
`
`hybrid or mixed algorithms that make use of aspects of two or more other
`
`algorithms.” EX1003 ¶47.
`
`For example, Core Based Trees (CBT), is a sophisticated routing algorithm
`
`that may be implemented on a logical tree topology that overlays the internet, and
`
`uses standard communication protocols. EX1003 ¶¶49-50; see also EX1031 at 85,
`
`-11-
`
`
`
`
`
`91; EX1032. CBT uses a single router (core node) at the “core” of the tree, from
`
`which branches emanate (non-core routers). EX1003 ¶49; see also EX1031 at 88.
`
`These branches include non-core routers (branch nodes), where a leaf router (leaf
`
`node) is at the end of a branch. EX1003 ¶49; see also EX1031 at 88. Member-
`
`hosts (client nodes) are connected to the router nodes. EX1003 ¶49; see also
`
`EX1031at 88. The CBT algorithm uses unicast routing to transmit a multicast
`
`packet onto the multicast tree, and once on the tree router-nodes direct the packets
`
`to the member-hosts. EX1003 ¶50; see also EX1031 at 90.
`
`
`
`Core-Assisted Mesh Protocol (CAMP), is another routing algorithm that
`
`uses “cores,” but for mesh topologies. EX1003 ¶51. “CAMP generalizes the
`
`notion of core-based trees introduced for internet multicasting into multicast
`
`meshes that have much richer connectivity than trees.” EX1033 at 784. “A
`
`-12-
`
`
`
`
`
`multicast mesh is a subset of the network topology that provides at least one path
`
`from each source to each receiver in the multicast group.... Because a member
`
`router of a multicast mesh has redundant paths to any other router in the same
`
`mesh, topology changes are less likely to disrupt the flow of multicast data and to
`
`require the reconstruction of the routing structures that support packet forwarding.”
`
`Id. at 785.
`
`Yallcast—a routing algorithm described in “Yallcast: Extending the Internet
`
`Multicast Architecture,” by Paul Francis (“Francis,” EX1005)—also utilizes a
`
`logical network overlaying a network such as the internet. EX1003 ¶52; see also
`
`EX1005 at 3. Yallcast utilizes two topologies: “a [] shared tree topology for
`
`efficient multicast distribution of application content, and a [] mesh topology, for
`
`robust broadcast distribution of various information, including control information
`
`and … application content.” EX1003 ¶52 (citing EX1005 at 5).
`
`Although the tree and the mesh topologies are comprised of common nodes,
`
`they are logically distinct and largely independent from one another. EX1003 ¶53.
`
`For instance, “[t]he two topologies are created for and optimized for different
`
`purposes, and so their creation is largely independent.” E.g., EX1005 at 12. “Each
`
`host can join or leave the two topologies (jointly called the tree-mesh)
`
`independently, making the group itself dynamic.” Id.
`
`-13-
`
`
`
`
`
`In Yallcast, “[t]he tree is the primary means of distributing content due to its
`
`relative efficiency.” EX1005 at 12. A node may transmit from any location on the
`
`tree (e.g., leaf, branch, root, etc.). EX1003 ¶54; EX1005 at 12. A node can receive
`
`data from any of its neighbors (omnidirectional), and will forward received data to
`
`all of its other neighbors. EX1003 ¶54; EX1005 at 12.
`
`
`
`Yallcast’s mesh network, as described by Francis, is primarily useful for
`
`transmitting management data, however, the mesh can also distribute content
`
`similar to the tree network. EX1003 ¶55; EX1005 at 12. Francis teaches that each
`
`mesh node is connected to a small number of randomly chosen other nodes.
`
`EX1003 ¶55; EX1005 at 14. Francis assumes that, on average, all nodes will have
`
`the same number of neighbors, but allows for other configurations. EX1003 ¶55;
`
`EX1005 at 14.
`
`-14-
`
`
`
`
`
`ii. Techniques for adding a node to a network
`
`While the ’634 patent discusses many of the above-described computer
`
`networking concepts, the subject claims are focused on a protocol for adding a
`
`node to a network of participants. EX1001 at cl. 19. Again, the claimed protocol
`
`requires the following five steps: (1) locating a portal computer; (2) requesting that
`
`portal computer provide an indication of neighbor participants to which the
`
`participant can be connected; (3) receiving the indications of those neighbor
`
`participants; (4) dropping the connection between the indicated neighboring
`
`participants (this is required in order to meet the limitation that the network is m-
`
`regular); and (5) establishing a connection between the participant and each of the
`
`indicated neighbor participants. See EX1003 ¶10. A person of ordinary skill in the
`
`art would know of many protocols for joining nodes to a network, including those
`
`recited in the subject claims. See EX1003 ¶¶18, 57, 75.
`
`For any network topology or routing algorithm, a node must first join a
`
`computer network to receive data. EX1003 ¶57. As Dr. Bambos explains, “[a]
`
`person of ordinary skill in the art would have many tools in her tool-box for joining
`
`nodes to a network such as those described above.” Id. Many such tools make use
`
`of a particular node that helps facilitate the addition of a joining node. Id.
`
`-15-
`
`
`
`
`
`CBT networks, discussed above, use a modified version of the Internet
`
`Group Management Protocol (“IGMP”)2 to facilitate a request to join the CBT
`
`network from a host node, through the router. EX1003 ¶¶58-59; see also EX1031
`
`at 91. In standard IGMP, a designated “Querier” router node periodically transmits
`
`messages asking nodes to identify any group memberships, and maintaining such
`
`information. EX1003 ¶58; see also EX1034 at 12-13; EX1035 at 4-5. See also
`
`EX1031 at 87, 91; EX1032 at 3:41-54. To join, a node must simply respond to the
`
`router’s query. EX1003 ¶58. For a CBT network, however, this join request also
`
`includes an identification of the core node of the CBT network. EX1003 ¶59;
`
`EX1031 at 91.
`
`In CBT, the “Querier” router node forwards the join request to the next-hop
`
`router along the path to the core node, which will forward the request along until it
`
`reaches the core node or a CBT-capable router that is already part of the multicast
`
`network, at which point the message terminates. EX1003 ¶¶58-59; EX1031 at 91.
`
`The router at the termination point determines whether to allow the join. EX1003
`
`¶59; EX1031 at 91. If the join request is allowed, an acknowledgement message
`
`will be sent back down to the requesting router, attaching the host node and any
`
`
`2 IGMP is the standard protocol used in IP Multicast. EX1003 ¶58; see also
`
`EX1034 and EX1035.
`
`-16-
`
`
`
`
`
`routers to the multicast network along that same path of the tree. EX1003 ¶59;
`
`EX1031 at 91.
`
`The CAMP network discussed above also uses a core node in its join
`
`protocol, and a joining node similarly starts the join process by using IGMP to
`
`interact with a local router. EX1003 ¶60; EX1033 at 784. However, unlike CBT,
`
`for a CAMP mesh network, the local router for the joining node first determines
`
`whether any of its neighboring routers are already members of the mesh. EX1003
`
`¶60. “A router sends a join request towards a core if none of its neighbors are
`
`members of the group; otherwise it simply announces its membership using either
`
`reliable or persistent updates.” EX1033 at 785. “Upon receiving a host request to
`
`join a group, the router then determines whether to announce its membership in the
`
`group or to request being added to the group, and uses its [Core-to-Group Address
`
`Mapping (CAM) table] to select the core towards which the join request may be
`
`sent.” Id. at 786.
`
`The concept of a designated node facilitating the joining process extends
`
`beyond the “cores” used in CBT and CAMP. See EX1003 ¶61. For example,
`
`other protocols known and used at the relevant time employed a Rendezvous Point
`
`(RP) to facilitate joining a new node to a network. See EX1003 ¶61; EX1036 at 2.
`
`The Francis reference employs such a technique for joining a node to its
`
`Yallcast distribution network. EX1003 ¶62. Francis uses a “rendezvous host” to
`
`-17-
`
`
`
`
`
`bootstrap new nodes in to its tree and mesh networks. EX1003 ¶62; EX1005 at 11.
`
`When a new node wishes to join one of Francis’s Yallcast networks, it first sends a
`
`join request directly to the associated rendezvous host. EX1003 ¶62; EX1005 at
`
`11. The rendezvous host manages the new nodes addition to tree and mesh
`
`networks. EX1003 ¶62; EX1005 at 11.
`
`To add the new node to the mesh network, the rendezvous host first informs
`
`the new node of several current members of the mesh network. EX1003 ¶63;
`
`EX1005 at 11. The new node joins the mesh network by communicating with
`
`these identified member nodes. The new node, however, does not necessarily
`
`connect to the identified nodes. EX1003 ¶63; EX1005 at 11. Instead, Francis’
`
`Yallcast protocol calls for the new node to connect to “random” member nodes.
`
`EX1003 ¶63; EX1005 at 14. To accomplish this “random” connection, Francis
`
`teaches that “[e]fficient random selection is achieved through a frame delivery
`
`mode called ‘mesh anycast’, whereby a discovery message takes a random walk
`
`along the mesh, randomly stopping at some member.” EX1005at 14. The new
`
`node will connect to the randomly identified members. EX1003 ¶63; EX1005 at
`
`14.
`
`The new member establishes only a small number (3 or 4) of connections
`
`with member nodes. EX1003 ¶64; EX1005 at 14. Francis teaches “that all nodes
`
`(including the new node) of the mesh will have the same number of connections,”
`
`-18-
`
`
`
`
`
`but also recognized that such regularity may not always be the case. See EX1003
`
`¶64; EX1005 at 14. “Nevertheless,” Dr. Bambos explains, “a person of ordinary
`
`skill in the art reading this disclosure would understand that they could use the
`
`network management resources provided by the rendezvous host to maintain
`
`regularity when adding new nodes if necessary (i.e., dynamically reconfiguring the
`
`network).” EX1003 ¶64
`
`A different protocol is used to add the new node to Francis’ tree network.
`
`EX1003 ¶65. Here, the new node selects its own parent node to attach itself to the
`
`tree. EX1005 at 26. Francis teaches several techniques for identifying a parent,
`
`but states that nodes “should pick parents that are nearby, by which I mainly mean
`
`a small latency.” Id. at 27. In one embodiment, the new node learns of potential
`
`parents from the rendezvous host. Id. at 26. In another embodiment, the new node
`
`selects a parent at random by sending a message that takes a random walk through
`
`the tree stopping at a potential new parent. Id.
`
`Other network joining algorithms made use of this concept of a designated
`
`node (e.g., a core or a rendezvous point) that manages the addition of a new node).
`
`EX1003 ¶66. For example, in a publication titled “A Scalable Multicast Routing,”
`
`the authors propose a “Designated Rendezvous Point multicast routing (DRP),” to
`
`act as a centralized management server that manages adding another node to a
`
`multicast network. EX1037 at 983-984. Here, when a designated router (“DR”)
`
`-19-
`
`
`
`
`
`receives a request to join a multicast network from a host node on its local
`
`network; that DR “sends a join message hop-by-hop along the unicast route to the
`
`DRP.” Id. at 984. When the join message is for a new group, the DRP selects a
`
`rendezvous point (“RP”) to act as the primary RP for the new group. Id. The
`
`protocol names several algorithms for the DRP to select the RP, one of which is
`
`random selection from a set of RPs. See id. at 984-985. The DRP then forwards
`
`the join request to the selected RP. Id. at 984. The selected RP then sends a join
`
`acknowledgement message hop-by-hop to the DR that originally sent the join
`
`request. Id. at 985. A network branch of the multicast tree is created along the
`
`acknowledgement message path to deliver messages to the host that originally
`
`requested to join the multicast network. See id.
`
`In some instances, the addition of a node requires changes to existing
`
`connections in a graph. EX1003 ¶67. For instance, U.S. Patent No. 6,603,742
`
`(“Steele”) discloses an algorithm to add a node to various topologies. EX1003
`
`¶67; EX1038 at 1:28-36. In particular, Steele discloses a technique for
`
`reconfiguring a topology (e.g., adding a node) of a network of nodes (e.g.,
`
`processors), while the network remains operational. EX1038 at 1:28-36, 1:63-67.
`
`The technique in Steele includes the step of identifying a pair of participants of the
`
`network that are connected, disconnecting the participants of the identified pair
`
`from each other, and connecting each participant of the identified pair of
`
`-20-
`
`
`
`
`
`participants to the added participant. See id. at 13:45-51, Figs. 5-6 (disclosing
`
`disconnecting nodes 3 and 1 from each other, and connecting each node to the
`
`added node 7).
`
`“Steele’s technique of disconnecting certain member nodes from one another
`
`and connecting those disconnected nodes to a joining node was well known in the
`
`art,” Dr. Bambos explains. EX1003 ¶68. For example, in a publication titled
`
`“Routing in the Manhattan Street Network,” author Nicholas Maxemchuk teaches
`
`using this disconnect/connect technique to add nodes to a Manhatttan Street
`
`Network. EX1028 at 503. Maxemchuck’s technique likewise includes identifying
`
`a pair of nodes in the network, breaking their connection, and then connecting each
`
`node to the new node. See id. at 508, Fig. 9.
`
`U.S. Patent No. 6,490,247 (“Gilbert”) teaches how the concepts discussed
`
`above, regarding a designated network management node and disconnecting a pair
`
`of nodes to add a new node to the network, may be combined. EX1003 ¶69.
`
`Gilbert discloses a “ring-ordered” communication network, where each node is
`
`logically connected to two other nodes. EX1021 at 3:5-6, 3:25-26. When a new
`
`node wants to join a ring network as in Gilbert, two adjacent nodes in the ring are
`
`identified, and those nodes drop their connection to each other, and connect to the
`
`new node, bringing the new node in to the ring-ordered communication network.
`
`Id. at 7:7-19; Fig 7. Gilbert further teaches that this disconnect/connect procedure
`
`-21-
`
`
`
`
`
`may be implemented in many different ways, some of which involve the use of a
`
`particular node that helps facilitate the addition of the joining node and some of
`
`which do not. EX1003 ¶69.
`
`For example, Gilbert teaches the use of a “primary node on the network that
`
`receives all incoming calls from other nodes wishing to enter the network.”
`
`EX1021 at 6:53-55; see also id. at 4:1-3 (teaching a “master node”); and 7:1
`
`(teaching a “gatekeeper” node). This primary node must be connected to the
`
`network at all times and performs the function of a network manager, which
`
`executes a joinder module. EX1003 ¶70; see also EX1021 at 4:1-3, 6:29-30
`
`(“joinder module within the network manager”).
`
`In that example, after the primary node receives a request to join the network
`
`from a new node, the primary node contacts a pair of adjacent nodes on the
`
`network and requests that they drop their connections to one another and connect
`
`with the new node. EX1003 ¶71; see also EX1021 at 4:1-3, 6:29-30, 6: 29-31, 7:7-
`
`13, Fig. 7; compare id. at claim 5, with id. at claim 23. In response to the request,
`
`the adjacent nodes then drop their connections, and the new node is then connected
`
`to the adjacent nodes. EX1003 ¶72; see also EX1021 at 7:12-18. “The
`
`connections may be initiated by any one of each adjacent node pair.” EX1021 at
`
`7:19-20.
`
`-22-
`
`
`
`
`
`The above-discussed procedure for joining a node to a network is but one
`
`example taught by Gilbert. EX1003 ¶73. “Indeed,” Dr. Bambos explains, “a
`
`person of ordinary skill in the art reading Gilbert would have understood that
`
`Gilbert teaches there being ample flexibility in the design and selection of
`
`techniques for adding nodes to networks.” Id.
`
`The procedures for adding a node to the logical ring network in Gilbert are
`
`not dependent on the underlying network, which may utilize a physical network
`
`with a switch, a physical network with various types of ISDN lines, or even
`
`another logical network. EX1003 ¶74; EX1021. at 3:8-19. That is, with respect to
`
`the underlying network, “any existing communications system capable of
`
`implementing two data channels and one control channel can be used, whether
`
`such arrangement is logical or physical.” EX1003 ¶74; EX1021 at 3:11-14.
`
`“[B]y July 2000,” Dr. Bambos concludes, “techniques for adding nodes to
`
`networks, as in the ’634 patent, were well-known in the field