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
`
`_____________________________
`
`DECLARATION OF DR. NICHOLAS BAMBOS, Ph.D.
`
`BUNGIE - EXHIBIT 1003
`
`
`_____________________________
`
`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,
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
