`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________________
`
`BUNGIE, INC.,
`Petitioner,
`
`v.
`
`ACCELERATION BAY, LLC,
`Patent Owner.
`
`_____________________________
`
`Patent No. 6,829,634
`
`_____________________________
`
`DECLARATION OF DR. NICHOLAS BAMBOS, Ph.D.
`
`BUNGIE - EXHIBIT 1003
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`QUALIFICATIONS ........................................................................................ 1
`
`SCOPE OF WORK.......................................................................................... 2
`
`III. OVERVIEW OF THE ’634 PATENT ............................................................ 3
`
`IV. RELATED PROSECUTION .......................................................................... 7
`
`V.
`
`LEGAL STANDARDS ................................................................................... 8
`
`VI. OVERVIEW OF THE SCOPE AND CONTENT OF THE ART ................ 12
`
`VII. LEVEL OF ORDINARY SKILL AND RELEVANT TIME ....................... 35
`
`VIII. CLAIM CONSTRUCTION .......................................................................... 36
`
`IX. BRIEF OVERVIEW OF THE PRIOR ART REFERENCES
`SUPPORTING THE GROUNDS OF UNPATENTABILITY ..................... 36
`
`X.
`
`GROUND OF UNPATENTABILITY BASED ON GILBERT IN
`VIEW OF FRANCIS ..................................................................................... 43
`
`XI. CONCLUDING STATEMENTS .................................................................. 67
`
`XII. APPENDIX – LIST OF EXHIBITS .............................................................. 68
`
`-i-
`
`
`
`I, Dr. Nicholas Bambos, Ph.D., declare as follows:
`
`I.
`
`QUALIFICATIONS
`
`1.
`
`I am R. Weiland Professor of Engineering at Stanford University,
`
`having a joint appointment in the Department of Electrical Engineering and the
`
`Department of Management Science & Engineering. I am also currently serving as
`
`the Fortinet Chairman of the Department of Management Science & Engineering.
`
`Before joining Stanford as an Associate Professor in 1996, I served as an Assistant
`
`Professor (1990-95), and tenured Associate Professor (1995-96) in the Electrical
`
`Engineering Department of the University of California at Los Angeles (UCLA). I
`
`received my Ph.D. from the University of California at Berkeley (1989) in
`
`Electrical Engineering and Computer Sciences (EECS). Also from U.C. Berkeley,
`
`I received a M.S. in EECS (1987), and a M.A. in Mathematics (1989). I graduated
`
`in Electrical Engineering from the National Technical University of Athens-Greece
`
`(1984) with first class honors.
`
`2.
`
`At Stanford University, I head the Network Architecture and
`
`Performance Engineering research group, working on high-performance design of
`
`computer systems and networks. From 1999 to 2005 I was the Director of the
`
`Stanford Networking Research Center project. I have held the Cisco Systems
`
`Faculty Development Chair (1999-2003) in computer networking at Stanford
`
`University and have won the IBM Faculty Development Award (2002) for research
`
`1
`
`
`
`in performance engineering of computer systems and networks. I have also been
`
`the recipient of the National Young Investigator Award of the National Science
`
`Foundation (1992). I have served as editor of various research journals (including
`
`the “Wireless Networks” and “Computer Networks” research journals), as
`
`technical reviewer for numerous networking and computing research journals, and
`
`on various technical panels for the National Science Foundation, etc.
`
`3.
`
`For over 25 years, I have done research in and taught
`
`computing/networking technology concepts and design principles (at Stanford
`
`since 1996 and at UCLA during 1989-96). I have graduated over 25 Ph.D.
`
`students who have then been in leadership positions in academia and the
`
`information technology industry (Stanford University, California Institute of
`
`Technology, Columbia University, New York University, University of Michigan;
`
`Cisco, IBM Labs, Qualcomm, ST Micro, Google, Intel, Nokia, MITRE, Sun Labs,
`
`Broadcom, Facebook, Twitter, etc.).
`
`4.
`
`My professional curriculum vitae, including my publications and
`
`patents, is submitted as Exhibit 1004
`
`II.
`
`SCOPE OF WORK
`
`5.
`
`I am informed by counsel that a petition is being filed with the United
`
`States Patent and Trademark Office requesting inter partes review of U.S. Patent
`
`-2-
`
`
`
`No. 6,829,634 to Holt et al. (the “’634 patent,” attached as Exhibit 1001), entitled
`
`“Broadcasting Network.”
`
`6.
`
`I have been retained by Bungie, Inc. (“Bungie”) to offer an expert
`
`opinion on the unpatentability of certain claims of the ’634 patent. I receive $450
`
`per hour for my work on this case, which is my standard rate. No part of my
`
`compensation is dependent on my opinions or on the outcome of this proceeding.
`
`7.
`
`Specifically, I have been asked to provide my opinions on claims 19-
`
`24 of the ’634 patent (“subject claims”). In connection with this analysis, I have
`
`reviewed the ’634 patent and its file history with respect to its original
`
`examination. I have also reviewed various other documents in arriving at my
`
`opinions. The documents relied upon in arriving at my opinions are listed in the
`
`Appendix to this declaration.
`
`III. OVERVIEW OF THE ’634 PATENT
`
`8.
`
`At the top of Column 1, the ’634 patent lists a set of nine patent
`
`applications all filed on the same day (July 31, 2000), one of which is the
`
`application that led to the ’634 patent.
`
`9.
`
`The subject claims are directed to a method for adding a participant to
`
`a network by “establishing a connection between the participant and … neighbor
`
`participants.” EX1001, claim 19 at 30:20-23, 30:30-31.
`
`-3-
`
`
`
`10. 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 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.
`
`11. 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.” Id. at 30:30-40.
`
`12.
`
`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
`
`-4-
`
`
`
`establishing connections to the joining participant (claim 23); and communications
`
`use the TCP/IP protocol (claim 24).
`
`13.
`
`I thus briefly address how the ’634 patent describes the key concepts
`
`pertinent to the subject claims: (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.
`
`14. 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.” Id. 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.
`
`15.
`
`Portal computers. When the specification describes portal computers,
`
`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
`
`-5-
`
`
`
`internal connections.”). Portal computers are nodes that are a point of contact for
`
`another node locating and joining the network. E.g., id. at 5:62-64 (“Each
`
`computer is aware of one or more ‘portal computers’ through which that computer
`
`may locate the broadcast channel.”); 12:64-66 (“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.
`
`16. 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. Id. at 14:10-13. “The process of breaking the connection
`
`between two neighbors and reconnecting each of the former neighbors to another
`
`computer [the joining node] is referred to as ‘edge pinning’ ....” Id. at 6:30-34.
`
`“Point-to-point connections” between nodes are also referred to as “edges.” Id. at
`
`4:51-53.
`
`-6-
`
`
`
`17.
`
`Figures 3A and 3B depict this step. 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.
`
`18. My opinion, as discussed further throughout this declaration, is the
`
`method for establishing connections among network participants claimed by the
`
`’634 patent subject claims—including, but not limited to, these key concepts
`
`discussed above—was well known and would have been obvious to those in this
`
`field.
`
`IV. RELATED PROSECUTION
`
`19.
`
`The original examination of the application that led to the ’634 patent
`
`included one (non-final) rejection, mailed on February 4, 2004. While I have
`
`reviewed the entire original file history in general (EX1002), I focus my discussion
`
`here on this aspect of the file history as it relates to my opinions herein.
`
`-7-
`
`
`
`20.
`
`The examiner found all then-pending claims anticipated by U.S.
`
`Patent 6,611,872 (“McCanne”). EX1002 at 0162. In response, the applicant
`
`amended its claims, and then argued distinctions over that patent. Id. at 0246-260.
`
`With regard to claim 19 of the ’634 patent (then-pending claim 44), the applicant
`
`added “non-routing table based” to the preamble, added the negative limitation
`
`“wherein a connection between the portal computer and the participant is not
`
`established,” and added the negative limitation “wherein a connection between the
`
`portal computer and the neighbor participants is not established.” EX1002 at 0256.
`
`The applicant then argued that “McCanne fails to disclose a non-routing table
`
`based method for routing information,” and fails to disclose the added negative
`
`limitations about portal computer connections. EX1002 at 0258-259.
`
`21.
`
`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.
`
`22.
`
`The examiner then allowed the pending claims, including what
`
`became claim 19 and its dependent claims 20-24. EX1002 at 264-270.
`
`V.
`
`LEGAL STANDARDS
`
`23.
`
`I am informed by counsel that in order for a reference to be
`
`considered a prior art publication it must be publicly accessible, meaning that the
`
`-8-
`
`
`
`reference has been disseminated or otherwise made available to the extent that
`
`persons interested and ordinarily skilled in the subject matter or art exercising
`
`reasonable diligence can locate it. I understand that a reference need only be
`
`accessible to interested members of the relevant public.
`
`24.
`
`I am informed by counsel that a claimed invention is not patentable
`
`under 35 U.S.C. § 103, for obviousness, if the differences between the invention
`
`and the prior art are such that the subject matter as a whole would have been
`
`obvious at the time the invention was made to a person having ordinary skill in the
`
`art to which the subject matter pertains.
`
`25.
`
`I am further informed by counsel that a determination of obviousness
`
`requires inquiries into: (1) the scope and contents of the art when the invention was
`
`made; (2) the differences between the art and the claims at issue; (3) the level of
`
`ordinary skill in the pertinent art when the invention was made; and, to the extent
`
`they exist, (4) secondary indicia of obviousness.
`
`26.
`
`I am informed by counsel that hindsight must not be used when
`
`comparing the prior art to the invention for obviousness. Thus, a conclusion of
`
`obviousness must be firmly based on knowledge and skill of a person of ordinary
`
`skill in the art at the time the invention was made without the use of post-filing
`
`knowledge.
`
`-9-
`
`
`
`27.
`
`I am informed by counsel that obviousness may be established by
`
`showing that it would have been obvious to combine the teachings of more than
`
`one item of prior art, and that in order for a claimed invention to be considered
`
`obvious, there must be some rational underpinning for combining cited references
`
`as proposed.
`
`28.
`
`I am informed by counsel that in determining whether a piece of prior
`
`art would have been combined with other prior art or with other information within
`
`the knowledge of one of ordinary skill in the art, the following are examples of
`
`approaches and rationales that may be considered:
`
`(a) Combining prior art elements according to known methods to yield
`predictable results;
`(b) Simple substitution of one known element for another to obtain
`predictable results;
`(c) Use of a known technique to improve similar devices (methods, or
`products) in the same way;
`(d) Applying a known technique to a known device (method, or
`product) ready for improvement to yield predictable results;
`(e) Applying a technique or approach that would have been “obvious
`to try” (choosing from a finite number of identified, predictable
`solutions, with a reasonable expectation of success);
`(f) Known work in one field of endeavor may prompt variations of it
`for use in either the same field or a different one based on design
`incentives or other market forces if the variations would have been
`predictable to one of ordinary skill in the art; or
`
`-10-
`
`
`
`(g) Some teaching, suggestion, or motivation in the prior art that
`would have led one of ordinary skill to modify the prior art reference
`or to combine prior art reference teachings to arrive at the claimed
`invention.
`29.
`I am informed by counsel that obviousness may also be shown by
`
`demonstrating that it would have been obvious to modify what is taught in a single
`
`piece of prior art to create the patented invention.
`
`30.
`
`I am informed by counsel that among the background knowledge
`
`possessed by a person of ordinary skill in the art, the person of ordinary skill in the
`
`art is presumed to be aware of the pertinent art.
`
`31.
`
`I am informed by counsel that, in the present proceeding, patent
`
`claims are to be given their broadest reasonable interpretation in view of and
`
`consistent with the specification. I also understand that, at the same time, claim
`
`terms are presumed to have their ordinary and customary meaning as would be
`
`understood by one of ordinary skill in the relevant field in the context of the entire
`
`patent disclosure (absent some reason to the contrary such as a special definition
`
`provided in the specification). Thus, I understand that whether an interpretation
`
`would be reasonable is considered from the perspective of one of ordinary skill in
`
`the art, taking into account whatever enlightenment by way of definitions or
`
`otherwise that may be afforded by the specification.
`
`-11-
`
`
`
`32.
`
`I have followed these principles in my analysis throughout this
`
`declaration.
`
`VI. OVERVIEW OF THE SCOPE AND CONTENT OF THE ART
`
`33.
`
`In my opinion, and as explained in further detail below, the subject
`
`claims of the ’634 patent would have been obvious to a person of ordinary skill in
`
`the art at the relevant time (i.e., prior to July 31, 2000).
`
`34.
`
`The subject claims are directed to employing basic and well-known
`
`concepts and procedures for adding a node to an existing computer network.
`
`35.
`
`In this section, I explain some well-known concepts and key
`
`terminology pertinent to the field of computer networks as of July 2000, and
`
`provide exemplary references that support my explanation. This discussion
`
`includes several types of topologies, which are ways to arrange the various parts of
`
`a computer network; and several different protocols and algorithms for distributing
`
`information throughout such networks. I then move on from these background
`
`concepts to discuss various known techniques for adding a node to such
`
`networks—i.e., the heart of the subject claims.
`
`36. Concepts and terminology. Computer networks and their topologies
`
`are routinely represented using graphs to depict or model relationships or
`
`connections between nodes. See, e.g., EX1001 at 4:49-52 (“The broadcast
`
`technique overlays the underlying network system with a graph of point-to-point
`
`-12-
`
`
`
`connections (i.e., edges) between host computers (i.e., nodes) through which the
`
`broadcast channel is implemented.”); EX10221 at 3:67-4:8.
`
`37.
`
`Typically, each node on a graph represents a participant (e.g.,
`
`computer, router, processor), and each edge (line) between two nodes represents a
`
`connection (communication) between them. EX1001 at 4:49-52; EX1022 at 3:67-
`
`4:8. The term neighbors refers to nodes that are directly connected by an edge to
`
`each other on the graph. See e.g., EX1001 at 4:49-52; EX1022 at 4:64-67.
`
`38.
`
`For example, in the graph drawn below, there are seven nodes
`
`numbered 1-5, 7-8, which are connected by seven links. Node 2 is directly
`
`connected to its neighbors (nodes 1 and 3), but not to the others (nodes 4, 5, 7, and
`
`8), with which it may only communicate indirectly (e.g., in this example, nodes 1
`
`and 3 could potentially communicate via node 2, but nodes 1 and 3 themselves are
`
`not directly connected).
`
`1 U.S. Patent No. 5,170,482 to Shu et al. (“Shu 482”). EX1022.
`
`-13-
`
`
`
`39.
`
`The connection between nodes can be physical connections or logical
`
`connections. See e.g., EX10232 at 53-54. A physical connection is where there is
`
`a point-to-point physical link (e.g., an Ethernet cable) connecting two nodes, and
`
`data is transmitted between these nodes via that physical link. See e.g., id. at 52.
`
`A logical connection (or virtual connection) represents a point-to-point data link
`
`between nodes, but has no particular regard for the underlying physical
`
`interconnection of the devices. See e.g., id. at 54. For example, in the below
`
`figure, while nodes A and F are not physically connected, a logical overlay has
`
`been implemented to the underlying network such that nodes A and F are logically
`
`connected directly to one another. EX10243 at 10–11.
`
`2 Frank et al., Multicast Communication on Network Computers, IEEE Software
`
`(1985) (“Frank 1985”). EX1023.
`
`3 Friesen et al., Resource Management with Virtual Paths in ATM Networks,
`
`IEEE Network (1996) (“Friesen 1996”). EX1024.
`
`-14-
`
`
`
`40.
`
`In graph theory, the degree of a node refers to the number of nodes to
`
`which it is connected, in other words, the number of neighbors it has. EX10254 at
`
`118; EX1022 at 4:10-12. A regular graph is one in which each node has the same
`
`degree (i.e., each node is connected to the same number of neighbors). EX1025 at
`
`118; EX10265 at 11 ¶2. An m-regular graph is one in which each node has degree
`
`m, in other words, a graph in which each node is connected to exactly m other
`
`nodes (i.e., has exactly m neighbors). See EX1001 at 4:64-5:1; EX1025 at 118.
`
`4 Dalal, Yogen Kantilal, Broadcast Protocols in Packet Switched Computer
`
`Networks, Ph.D. dissertation, Stanford University (1977) (“Dalal”). EX1025.
`
`5 Chen et al., Addressing, Routing, and Broadcasting in Hexagonal Mesh
`
`Multiprocessors, IEEE Transactions on Computers (1990) (“Chen 1990”).
`
`EX1026.
`
`-15-
`
`
`
`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:
`
`41.
`
`Topologies. The above network is arranged in a regular mesh
`
`topology. See EX1026 at 11 ¶1. Other regular network topologies include, ring,
`
`torus, Manhattan street network, and hypercube (respectively illustrated below).
`
`See e.g., EX1022 at 4:53-57, 6:4-21, Fig. 1C (ring), Fig. 2D (hypercube); EX10276
`
`at 324 ¶5, Fig. 1 (torus); EX10287 at 510 ¶2, Fig. 1 (Manhattan street network).
`
`6 Fragopoulou et al., Efficient Algorithms for Global Data Communication on
`
`the Multidimensional Torus Network, Parallel Processing Symposium
`
`Proceedings, IEEE (1995) (“Fragopoulou 1995”). EX1027.
`
`7 Maxemchuk, Nicholas F., Routing in the Manhattan Street Network, IEEE
`
`Transactions on Communications (1987) (“Maxemchuk”). EX1028.
`
`-16-
`
`
`
`Ring
`
`EX1022 Fig. 1C
`
`Torus
`
`1027 Fig. 1
`
`Manhattan Street Network
`EX1028 Fig. 1
`42. Regular topologies can be incomplete (i.e., each node is connected to
`
`Hypercube
`EX1022 Fig. 2D
`
`less than all other nodes) as shown in the above examples, or complete (i.e., each
`
`node is connected to all other nodes) as shown below in the following figure. See,
`
`e.g., EX1026 at 11 ¶1, Fig. 6 (illustrating a 6-regular incomplete mesh); EX1022 at
`
`5:4-7, Fig. 1F (illustrating a 7-regular complete mesh). A node in a complete
`
`-17-
`
`
`
`topology is sometimes referred to as “fully connected,” meaning it has a direct
`
`connection to every other node.
`
`EX1022 Fig. 1F.
`
`43. Network topologies may also be non-regular. A network is non-
`
`regular when nodes have different degrees (i.e., nodes have a different number of
`
`neighbors). See e.g., EX1026 at 11 ¶2. Non-regular topologies include tree and
`
`non-regular mesh (respectively illustrated below). See e.g., EX1022 at 4:61-62,
`
`Fig. 1D (tree); EX1026 at 11 ¶1, Fig 2 (mesh).
`
`-18-
`
`
`
`Tree
`EX1022 Fig. 1D
`
`Mesh
`
`EX1026 Fig. 2.
`
`44. All network topologies share a basic purpose, to facilitate the
`
`distribution of data among each of the participants of a network. See e.g., EX1023
`
`at 49 ¶1 (“Communication is essential to distributed systems…”).
`
`45.
`
`The different types of network topologies have various advantages
`
`and disadvantages. See e.g., EX1026 at 16 ¶5-17 ¶4 (comparing several
`
`topologies). Nevertheless, given their common purpose, concepts and protocols
`
`developed for or applicable to one topology are often applicable or adaptable for
`
`use in another topology. See, e.g., EX10298 at 387 ¶1 (“Often, the results
`
`developed for meshes [] can be extended to tori with suitable modifications…”).
`
`In general, in the field of computer networks, a broad variety of interconnection
`
`topologies has been considered.
`
`8 Chalasani et al., Adaptive Wormhold Routing in Tori with Faults, IEE
`
`Proceedings – Computers and Digital Techniques (1995) (“Chalasani”). EX1029.
`
`-19-
`
`
`
`46. Data transmission algorithms and protocols. Routing algorithms, of
`
`which there are many, describe the manner in which data propagates through a
`
`network. See, e.g., EX10309 at abstract; EX1023 generally. Generally speaking,
`
`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. See e.g., id. at 51. Such algorithms make use of protocols,
`
`of which there are also many, and which define certain rules for network
`
`communications. TCP/IP (Transmission Control Protocol/Internet Protocol) is one
`
`such well-known protocol, and is a primary protocol used for internet
`
`communications.
`
`47. A person of ordinary skill in the art 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.
`
`48.
`
`In many routing algorithm implementations, certain nodes have
`
`designated functionality or responsibilities. A basic example is a client-server
`
`implementation, where a server node provides resources used by client nodes. A
`
`client may transmit information to a server, which may then make it available to
`
`other clients. One reason to make use of a central server is for security purposes.
`
`9 U.S. Patent No. 5,056,085 to Vu (“Vu 085”). EX1030.
`
`-20-
`
`
`
`A server may control or restrict access to information and services, such as by
`
`requiring client authorization like a password or certificate.
`
`49. A more sophisticated example, Core Based Trees (CBT), is a routing
`
`algorithm that may be implemented on a tree topology that overlays the internet.
`
`EX103110 at 85; see also EX1032.11 CBT uses a single router (core node) at the
`
`“core” of the tree, from which branches emanate. EX1031 at 88. These branches
`
`include non-core routers (branch nodes) which are connected in a “shortest-path”
`
`configuration. See id. A leaf router (leaf node) is at the end of a branch. See id.
`
`Member-hosts (client nodes) are connected to the router nodes. See id.
`
`10 Ballardie et al., Core Based Trees (CBT): An Architecture for Scalable Inter-
`
`Domain Multicast Routing, ACM SIGCOMM Computer Communication Review
`
`(1993) (“Ballardie & Francis 1993”). EX1031.
`
`11 U.S. Patent No. 5,331,637 to Francis et. al. EX1032.
`
`-21-
`
`
`
`50.
`
`The CBT routing algorithm is an overlay of the IP unicast and IP
`
`multicast algorithms underlying certain internet communications. See id. at 91.
`
`The CBT algorithm uses unicast routing to transmit a multicast packet on to the
`
`multicast tree. See id. at 90. Once on the tree, the multicast-capable routers direct
`
`the packets along the braches to the member-hosts. See id.
`
`51. Another routing algorithm, the Core-Assisted Mesh Protocol
`
`(CAMP), also uses “cores,” but for mesh topologies. “CAMP generalizes the
`
`notion of core-based trees introduced for internet multicasting into multicast
`
`-22-
`
`
`
`meshes that have much richer connectivity than trees.” EX103312 at 784. “A
`
`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.
`
`52.
`
`“Yallcast: Extending the Internet Multicast Architecture,” by Paul
`
`Francis (“Francis,” EX1005) describes yet another routing algorithm—Yallcast—
`
`which also utilizes a logical network overlaying a network such as the internet. Id.
`
`at 3. Francis 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.” Id. at 5.
`
`12 Garcia-Luna-Aceves et al., A Multicast Routing Protocol for Ad-Hoc
`
`Networks, INFOCOM'99, Eighteenth Annual Joint Conference of the IEEE
`
`Computer and Communications Societies, IEEE (1999) (“Garcia-Luna-Aceves”).
`
`EX1033.
`
`-23-
`
`
`
`53. Although the two topologies of Francis are comprised of common
`
`nodes, the tree and the mesh are logically distinct and largely independent from
`
`one another. For instance, Francis describes: “[t]he two topologies are created for
`
`and optimized for different purposes, and so their creation is largely independent.”
`
`E.g., Id. at 12. “Each host can join or leave the two topologies (jointly called the
`
`tree-mesh) independently, making the group itself dynamic.” Id.
`
`54.
`
`In Francis, “[t]he tree is the primary means of distributing content due
`
`to its relative efficiency.” Id. at 12. A node may transmit from any location on the
`
`tree (e.g., leaf, branch, root, etc.). Id. A node can receive data from any of its
`
`neighbors (omnidirectional), and will forward received data to all of its other
`
`neighbors. Id. A node can transmit to its neighbors using IP unicast or IP
`
`multicast. When neighbors communicate with IP unicast, their relationship is
`
`“parent/child”. When IP multicast is used, “a set of members are grouped as a
`
`cluster.” Here, one member of the cluster is the “head”, and establishes a unicast
`
`connection with its parent neighbor, thus bringing its cluster onto the tree. The
`
`head will multicast the data it receives to its cluster neighbors. Id. at 13.
`
`-24-
`
`
`
`EX1005 Fig. 1
`
`55.
`
`The mesh network is described by Francis as primarily useful for
`
`transmitting management data, however, this network can also distribute content
`
`similar to the tree network. Id. at 12. In Francis, each mesh node is connected to a
`
`small number of randomly chosen other nodes. Id. at 14. The mesh topology is
`
`“robust” and “non-partitioned,” thus each node of Francis’s network is a member
`
`of the mesh. Id. Francis assumes that, on average, all nodes will have the same
`
`-25-
`
`
`
`number of neighbors. Id. However, Francis allows for other configurations. See
`
`id.
`
`56.
`
`Francis describes several modes of propagating data between its
`
`nodes. See id. at 17. These modes include “multicast (over the tree, primarily),
`
`broadcast (over the mesh), two types of anycast (over the tree and over the mesh),
`
`and unicast.” Id.
`
`57. Adding a node to a network. Regardless of the network topology or
`
`routing algorithm, a node must first join a computer network to receive data. 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. Many of these procedures make
`
`use of a particular node that helps facilitate the addition of a joining node.
`
`58.
`
`IP multicast, for example, uses the Internet Group Management
`
`Protocol (“IGMP”) for adding new nodes to a multicast network. This is described
`
`in Internet Engineering Task Force13 Request for Comment No. 1112, which
`
`provides the original IGMP standard, and No. 2236, which updates for IGMP
`
`version 2. EX1034; EX1035. In IGMP, a router node is designated as the
`
`“Querier,” which is responsible for managing multicast group membership. It does
`
`13 The IETF is the standards-setting body for the internet, and its standards are
`
`published as Requests for Comment.
`
`-26-
`
`
`
`this by periodically transmitting messages asking nodes to identify any group
`
`memberships, and maintaining such information. 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.
`
`59. A node wishing to join the CBT network discussed above may use
`
`IGMP to facilitate a request to join the CBT network from a host node, through the
`
`router. EX1031 at 91. For a CBT network, however, this join request also
`
`includes an identification of the core node of the CBT network. Id. The 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,