`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`ACTIVISION BLIZZARD, INC.,
`ELECTRONIC ARTS INC.,
`TAKE-TWO INTERACTIVE SOFTWARE, INC.,
`2K SPORTS, INC.,
`ROCKSTAR GAMES, INC.,
`Petitioners
`
`v.
`
`ACCELERATION BAY, LLC,
`Patent Owner
`________________
`
`Case No. IPR2016-00726
`Patent 6,910,069 B1
`________________
`
`PATENT OWNER PRELIMINARY RESPONSE TO PETITION
`PURSUANT TO 37 C.F.R. §42.107
`
`
`
`
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`TABLE OF CONTENTS
`
`Page
`
`TABLE OF AUTHORITIES ................................................................................... iii
`I.
`INTRODUCTION ........................................................................................... 1
`II.
`THE ‘069 PATENT ......................................................................................... 3
`III. CLAIM CONSTRUCTION .......................................................................... 10
`IV. SPECIFIC REASONS WHY THE CITED REFERENCES DO
`NOT INVALIDATE THE CLAIMS, AND WHY INTER
`PARTES REVIEW SHOULD NOT BE INSTITUTED ................................ 10
`A. Ground 1: Claims 1–3, 7–9, and 11–17 are Patentable
`Over Obrazcka in view of Denes and Shoubridge ............................... 11
`1.
`Obraczka in view of Denes and Shoubridge Fails to
`Disclose “a seeking [participant/node] [that] contacts a
`fully connected portal [computer/node]” (claims 1 and
`14) ............................................................................................. 15
`
`2.
`
`3.
`
`Obraczka in view of Denes and Shoubridge Fails to
`Disclose “a fully connected portal [computer/node]
`which in turn sends an edge connection request to a
`number of randomly selected neighboring
`[participants/nodes] to which the seeking
`[computer/node] is to connect” (claims 1 and 14) .................... 19
`
`The Petition Provides Inadequate Motivation to
`Combine the Obraczka, Denes, and Shoubridge
`References ................................................................................. 26
`
`B.
`
`Ground 2: Claims 4–6 and 10 are Patentable Over
`Obrazcka in view of Denes Shoubridge, and Valiant .......................... 30
`1.
`Obraczka in view of Denes, Shoubridge, and Valiant
`Fails to Disclose “wherein the randomly selecting of a
`pair includes sending a message through the network on
`a randomly selected path” (claim 4) ......................................... 31
`
`2.
`
`Obraczka in view of Denes, Shoubridge, and Valiant
`Fails to Disclose “wherein when a participant receives
`
`i
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`the message, the participant sends the message to a
`randomly selected participant to which it is connected”
`(claim 5) .................................................................................... 32
`
`CONCLUSION .............................................................................................. 33
`V.
`CERTIFICATE OF SERVICE ................................................................................ 36
`
`
`
`- ii -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`ActiveVideo Networks, Inc. v. Verizon Commc’n, Inc.,
`694 F.3d 1312 (Fed. Cir. 2012) .................................................................... 19, 27
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ............................................................................................ 32
`
`In re Ratti,
`270 F.2d 810, 123 USPQ 349 (CCPA 1959) ...................................................... 29
`
`Travelocity.com L.P. v. Conos Techs., LLC,
`CBM2014-00082 (PTAB Oct. 16, 2014) ............................................................. 2
`
`OpenTV, Inc. v. Cisco Tech., Inc.,
`IPR2013-00328 (PTAB Nov. 29, 2013) ............................................................. 27
`
`Unigene Labs., Inc. v. Apotex, Inc.,
`655 F.3d 1352 (Fed. Cir. 2011) .......................................................................... 17
`
`Statutes
`
`35 U.S.C. § 103 ........................................................................................................ 11
`
`Other Authorities
`
`37 C.F.R. § 42.104(b) .......................................................................................... 2, 20
`
`37 C.F.R. § 42.108(c) ................................................................................................. 1
`
`
`
`
`
`- iii -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`PATENT OWNER’S EXHIBIT LIST
`
`Exhibit Number Description
`
`Ex. 2001
`
`Declaration of Michael Goodrich, Ph.D.
`
`- iv -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`I.
`
`INTRODUCTION
`
`On March 12, 2016, Petitioner filed a Petition for inter partes review of
`
`claim 1–17 of U.S. Patent No. 6,910,069 B1 (Ex. 1101, the “‘069 Patent”), which
`
`issued to The Boeing Company on June 21, 2005, based on an application filed in
`
`the USPTO on July 31, 2000. Acceleration Bay LLC (“Acceleration Bay” or
`
`“Patent Owner”) requests that the Board not institute inter partes review because
`
`Petitioner has not demonstrated a reasonable likelihood that it would prevail in
`
`showing unpatentability of any of the challenged claims on the grounds asserted in
`
`its Petition as required under 37 C.F.R. § 42.108(c).
`
`The ‘069 Patent is one of several patents obtained by Boeing directed to
`
`novel computer network technology, developed by inventors Fred Holt and Virgil
`
`Bourassa more than sixteen years ago, that solved critical scalability and
`
`reliability problems associated with the real-time sharing of information among
`
`multiple widely distributed computers. This innovative technology enabled large-
`
`scale, online collaborations with numerous participants continually joining and
`
`leaving—with applications ranging from aircraft design development to multi-
`
`player online games. A core feature of the patented technology claimed in the
`
`‘069 Patent is the manner in which a node or participant is added to a network,
`
`which involves a fully-connected portal computer randomly identifying pairs of
`
`- 1 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`connected computers, disconnecting the individual participants in the identified
`
`pair(s), and connecting a seeking computer to each participant.
`
`The references cited in Grounds 1 and 2 of the Petition do not disclose the
`
`approach to joining a network disclosed in the ‘069 Patent. For example, and in
`
`addition to further deficiencies, Petitioner has failed to meet its burden under 37
`
`C.F.R. § 42.104(b) to demonstrate that the cited references disclose:
`
` a seeking participant/node contacting a fully connected portal
`computer, which in turn sends an edge connection request to a number
`of randomly selected neighbouring participants/nodes (all independent
`claims);
` wherein identifying of a pair includes randomly selecting a pair of
`participants that are connected (dependent claim 3);
` wherein the randomly selecting of a pair includes sending a message
`through the network on a randomly selected path (dependent claim 4);
`and
` wherein when a participant receives the message, the participant sends
`the message to a randomly selected participant to which it is
`connected (dependent claim 5).
`Although there are a variety of reasons why the ‘069 Patent is valid over
`
`Petitioner’s asserted prior art references, this Preliminary Response focuses on
`
`only limited reasons why inter partes review should not be instituted. See
`
`Travelocity.com L.P. v. Conos Technologies, LLC, CBM2014-00082, Paper 12 at
`
`10 (PTAB Oct. 16, 2014) (“[N]othing may be gleaned from the Patent Owner’s
`
`- 2 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`challenge or failure to challenge the grounds of unpatentability for any particular
`
`reason.”). Regardless, the deficiencies of the Petition noted herein, however, are
`
`more than sufficient for the Board to find that Petitioner has not met its burden to
`
`demonstrate a reasonable likelihood that it would prevail in showing
`
`unpatentability of any of the challenged claims.
`
`II. THE ‘069 PATENT
`
`As discussed in the Background of the Invention section of the ‘069 Patent
`
`(the “Background”), point-to-point network protocols, such as UNIX pipes,
`
`TCP/IP, and UDP, allow processes on different computers to communicate via
`
`point-to-point connections. ’069 Patent at 1:44–46. However, the interconnection
`
`of all participants using point-to-point connections, while theoretically possible,
`
`does not scale well as the number of participants grows. Id. at 1:46-49. Because
`
`each participating process needs to manage its direct connections to all other
`
`participating processes, the number of possible participants is limited to the
`
`number of direct connections a given machine, or process, can support. Id. at
`
`1:49–55.
`
`On the other end of the connectivity spectrum are client/server middleware
`
`systems that have a single server that does not communicate with any other server
`
`and coordinates all communications between various clients who are sharing the
`
`information. Id. at 1:58–60. These systems rely on the sole server to function as a
`
`- 3 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`central authority for controlling all access to shared resources. Id. at 1:60–62.
`
`Such systems are also not well suited to sharing of information among many
`
`participants, but for different reasons than point-to-point networks. When a client
`
`stores information to be shared at the server, every other client must poll the server
`
`to determine that the new information is being shared, which places a very high
`
`overhead on the communications network. Id. at 1:65–2:4. Alternatively, each
`
`client can register a callback with the server, which the server then invokes when
`
`new information is available to be shared. Id. at 2:4–6. However, such callback
`
`techniques create a performance bottleneck. A single server needs to effect a
`
`callback to each and every client whenever new information is to be shared. In
`
`addition, the reliability of the entire information sharing depends upon that of a
`
`single server; failure at the single server prevents all communications between any
`
`clients. Id. at 2:7–13.
`
`The ‘069 Patent is one of several patents obtained by Boeing directed to its
`
`novel computer network technology that solved the central bottleneck problem of
`
`client/server networks, as well as the problems of management complexity and
`
`limited supported connections of point-to-point networks. More particularly, the
`
`‘069 Patent describes using a broadcast channel that overlays a point-to-point
`
`network where each node, or participant, is connected to some—but not all—
`
`neighboring participants. For example, Fig. 2 of the ‘069 Patent, reproduced
`
`- 4 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`below, shows a network of twenty participants, where each participant is connected
`
`to four other participants:
`
`
`Id. at Fig. 2. Such a network arrangement, where each node in the network, is
`
`connected to the same number of other nodes, is known as an m-regular network.
`
`Id. at 4:38–39. That is, a network is m-regular when each node is connected to m
`
`other nodes at least some of the time, and a computer would become disconnected
`
`from the broadcast channel only if all m of the connections to its neighbouring
`
`nodes fail. Id. at 4:39–42. In Fig. 2 above, m=4 because each node is connected to
`
`four other nodes of the network. A network is said to be m-connected when it
`
`- 5 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`would take a failure of m computers to divide the graph into disjoint sub-graphs,
`
`i.e., separate broadcast channels. Id. at 4:42–45. The ‘069 Patent also describes a
`
`computer network in which the number of network participants N (in Fig. 2, this is
`
`twenty) is greater than the number of connections m to each participant (in Fig. 2,
`
`this is four). Id. at Fig. 2. This network topology, where no node is connected to
`
`every other node, is known as an incomplete graph.
`
`The incomplete graph topology relies on participants to disseminate
`
`information to other participants. See id. at 1:58-2:13. As described in the ‘069
`
`Patent, to broadcast a message, the originating computer sends the message to each
`
`of its neighbors using the overlay network. Id. at 7:30-36. Each computer that
`
`receives the message then sends the message to its three other neighbors using the
`
`network. Id. at 7:37-49. In this way, the message is propagated to each computer
`
`of the overlay network using the underlying network, thus broadcasting the
`
`message to each computer over a logical broadcast channel.
`
`The invention claimed in the’069 Patent focuses on a process for adding
`
`nodes, or participants, to an existing network. In order to join an existing network,
`
`a seeking computer (e.g. node Z in Fig. 3B) locates and contacts a portal computer
`
`that is fully connected to the network. Id. at 5:20–22. The portal computer then
`
`identifies computers to which the seeking computer will connect. Id. at 5:42–45.
`
`- 6 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`Once identified, the seeking computer joins the network by connecting to the
`
`identified computers using the ‘069 Patent’s edge pinning process.
`
`Figs. 3A and 3B of the ‘069 Patent, reproduced below, illustrate the process
`
`of breaking connections between nodes (i.e., “edges”) in a graph to add new node
`
`Z. In particular, Fig. 3A illustrates a graph that includes edges (cid:2161)(cid:2158) and (cid:2160)(cid:2159). In
`order to add new node Z to the graph, edges (cid:2161)(cid:2158) and (cid:2160)(cid:2159) are broken, and edges (cid:2161)(cid:2182),
`(cid:2158)(cid:2182),(cid:2160)(cid:2182) and (cid:2159)(cid:2182) are added:
`
`
`Id. at Figs. 3A and 3B. As described in the ‘069 Patent, when a computer seeks to
`
`join a broadcast channel, previously connected computers break connections to
`
`each other in favor of new connections to the seeking computer:
`
`Thus, some connections between computers need to be broken so that
`the seeking computer can connect to four computers. In one
`embodiment,
`the broadcast
`technique
`identifies
`two pairs of
`
`- 7 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`computers that are currently connected to each other. Each of these
`pairs of computers breaks the connection between them, and then
`each of the four computers (two from each pair) connects to the
`seeking computer. FIGS. 3A and 3B illustrate the process of a new
`computer Z connecting to the broadcast channel. FIG. 3A illustrates
`the broadcast channel before computer Z is connected. The pairs of
`computers B and E and computers C and D are the two pairs that are
`identified as the neighbors for the new computer Z. The connections
`between each of these pairs is broken, and a connection between
`computer Z and each of computers B, C, D, and E is established as
`indicated by FIG. 3B. The process of breaking the connection
`between two neighbors and reconnecting each of the former
`neighbors to another computer is referred to as “edge pinning” as
`the edge between two nodes may be considered to be stretched
`and pinned to a new node.
`
`Id. at 5:58-6:9 (emphasis added).
`
`The ‘069 Patent describes a problem that arises when a seeking computer
`
`connects to computers directly connected to the portal computer or directly
`
`connected to one of its neighbors: the diameter of the network increases as it
`
`“becomes elongated in the direction of where the new nodes are added.” See id. At
`
`6:63–7:6. This issue is illustrated in FIGS. 4A–4C, reproduced below:
`
`- 8 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`
`
`
`
`Although Figs. 4B and 4C both illustrate graphs in which node K has been added
`
`to the graph shown in Fig. 4A, the diameter of the graph of Fig. 4B is three
`
`(because the longest, shortest path between two nodes (e.g. G and K) traverses
`
`three edges, (cid:2163)(cid:2157), (cid:2157)(cid:2161), and (cid:2161)(cid:2167)), while the diameter of the graph of Fig. 4C remains
`two edges, (cid:2165)(cid:2163) and (cid:2163)(cid:2167)).
`
`two (because the longest, shortest path between nodes, (e.g. I and K) traverses only
`
`In order to minimize the diameter of the graph as new nodes are added, the
`
`‘069 Patent describes a “random selection technique to identify” neighbors for a
`
`seeking computer. Id. at 7:20–24. This technique minimizes the graph diameter
`
`by distributing connections for new seeking computers throughout the graph
`
`instead of allowing the graph to elongate in any one direction. Id. at 7:25–28. In
`
`order to randomly select the computers to which the seeking computer will
`
`connect, the “portal computer sends an edge connection request through one of its
`
`internal connections that is randomly selected.” Id. at 13:36–38. The receiving
`
`computer then sends the edge connection request on a random one of its internal
`
`connections, and so on, until “the message has traveled far enough to represent a
`
`- 9 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`randomly selected computer.” Id. at 13:38–45. The randomly selected computer
`
`offers the internal connection on which it received the request to the seeking
`
`computer for edge pinning. Id. at 13:45–48.
`
`III. CLAIM CONSTRUCTION
`
`Patent Owner respectfully submits, without prejudice, that, for purposes of
`
`this Patent Owner Preliminary Response, it is not necessary to construe any term in
`
`the claims of the ‘069 Patent.
`
`IV. SPECIFIC REASONS WHY THE CITED REFERENCES DO NOT
`INVALIDATE THE CLAIMS, AND WHY INTER PARTES REVIEW
`SHOULD NOT BE INSTITUTED
`
`Petitioner’s proposed Grounds rely on four references: (1) Katia Obraczka,
`
`Massively Replicating Services in Wide-Area Internetworks, Ph.D. Thesis,
`
`University of Southern California (Ex. 1010, “Obraczka”); (2) Tamás Denes, The
`
`“Evolution” of Regular Graphs of Even Order by their Vertices, Matematikai
`
`Lapok, 27, 3–4 (Ex. 1016);1 (3) Peter J. Shoubridge et al., Hybrid Routing in
`
`Dynamic Networks, IEEE International Conference on Communications (Ex. 1005,
`
`“Shoubridge”); and (4) L.G. Valiant, Optimality of a Two-Phase Strategy for
`
`Routing in Interconnection Networks,” IEEE Transactions on Computers
`
`(Ex. 1027, “Valiant”). In particular, Petitioner’s Ground 1 proposes that claims 1–
`
`1 Patent Owner reserves its right to object to the accuracy of the English language
`
`translation of Ex. 1016, provided as Ex. 1017 (“Denes”).
`
`- 10 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`3, 7–9, and 11–17 of the ‘069 Patent are obvious under pre-AIA 35 U.S.C.
`
`§ 103(a) over Obraczka in view of Denes and Shoubridge, and Petitioner’s Ground
`
`2 proposes that claims 4–6, 9, and 10 of the ’069 Patent are obvious over Obraczka
`
`in view of Denes, Shoubridge, and Valiant.
`
`There are several reasons, however, that the Board should decline to institute
`
`inter partes review of the ‘069 Patent, including that the proposed combinations of
`
`Obraczka, Denes, and Shoubridge do not teach the subject matter of independent
`
`claims 1 and 14, and that a POSITA would not have combined the cited references
`
`in the manner suggested at the time the ‘069 Patent was invented.
`
`A. Ground 1: Claims 1–3, 7–9, and 11–17 are Patentable Over
`Obrazcka in view of Denes and Shoubridge
`
`Obrazcka in view of Denes and Shoubridge does not disclose “identifying a
`
`pair of participants of the network that are connected wherein a seeking participant
`
`contacts a fully connected portal computer, which in turn sends an edge connection
`
`request to a number of randomly selected neighboring participants to which the
`
`seeking participant is to connect” (independent claim 1) or “identifying p pairs of
`
`nodes of the graph that are connected, where p is one half of m, wherein a seeking
`
`node contacts a fully connected portal node, which in turn sends an edge
`
`connection request to a number of randomly selected neighboring nodes to which
`
`the seeking node is to connect” (independent claim 14). More specifically, the
`
`combination of Obraczka, Denes, and Shoubridge is silent with respect to:
`
`- 11 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
` “a seeking [participant/node] [that] contacts a fully connected portal
`
`[computer/node]” and
`
` “a fully connected portal [computer/node] which in turn sends an edge
`
`connection request to a number of randomly selected neighboring
`
`[participants/nodes] to which the seeking [computer/node] is to
`
`connect.”
`
`Petitioner relies solely on Obraczka for these claim elements. See Petition at
`
`26–27 (relying on Obraczka as allegedly disclosing “a seeking participant contacts
`
`a fully connected portal computer, which in turn sends an edge connection request
`
`to a number of randomly selected neighboring participants to which the seeking
`
`computer is to connect”).2 However, as demonstrated below, Petitioner’s reliance
`
`on Obraczka for these claim elements is misplaced at least because Obraczka’s
`
`procedure for calculating new network topologies does not utilize edge connection
`
`requests or random selection of neighboring participants to which the seeking
`
`computer is to connect.
`
`Obraczka purports to be a doctoral thesis that describes a mechanism for
`
`replicating information across the Internet. In particular, Obraczka is concerned
`
`with providing “an architecture for efficient massive replication of wide-area,
`
`2 Denes is relied upon only for its alleged disclosure of “identifying a pair of
`
`participants of the network that are connected.” Id. at 27.
`
`- 12 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`autonomously managed services.” Obraczka at pg. 8, ¶ 1.3 The disclosed
`
`architecture envisions “cluster[ing] replicas of a service into multiple,
`
`autonomously administered replication groups imitating the Internet’s
`
`administrative domain hierarchy.” Id. at pg. 12, ¶ 1. Figure 2.1 of Obraczka
`
`illustrates the relationship between logical and physical network topologies in its
`
`architecture:
`
`
`
`When a change is detected in the physical topology of the members of a
`
`replication group, a new topology is calculated and flooded to all members of the
`
`group. Id. at pg. 15, ¶ 2; see also id. at pg. 20, ¶ 4 (describing how a “group
`
`3 Petitioner has chosen to cite to the original page numbers of the Obraczka
`
`reference rather than the page numbers provided in the exhibit labels. To avoid
`
`confusion, Patent Owner has adopted this citation scheme in this paper.
`
`- 13 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`master” computes new logical update topologies for a group, and “if the new
`
`topology is significantly better than the old, distributes it to all the group
`
`members”). Obraczka explains its procedure for adding a replica to a replication
`
`group requires the new replica to communicate its existence to the rest of the
`
`group, at which time the group master computes a new topology:
`
`Replicas may join or leave a replication group at any time. To join a
`group, a new replica copies a neighbor’s database, and floods its
`existence to the rest of the group. When a new member joins the
`group, a topology calculation is spawned. The resulting topology
`includes the new replica and is distributed to the group.
`
`Id. at pg. 20, ¶ 7.
`
`Notably, Obraczka’s procedure for adding a replica to a group does not
`
`involve any computer sending edge connection requests at all, let alone to a
`
`number of randomly selected neighboring participants or nodes, as claimed in the
`
`challenged independent claims of the ‘069 Patent. Rather, Obraczka describes first
`
`generating a starting topology “by generating random topologies until it finds one
`
`that is feasible,” meaning that “it satisfies the specified connectivity requirement.”
`
`Obraczka at 40, ¶ 2. After a feasible starting topology is found, Obraczka discloses
`
`applying transformations to the initial configuration, which might include X-
`
`change, split, delete, and add transformations. Id. at pg. 43, ¶¶ 2–3. These
`
`transformations are not used to add a new replica to the group because these
`
`- 14 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`transformations are only applied to an already generated, feasible configuration
`
`that includes the new replica. Id. (“The next step is to apply transformation to the
`
`initial configuration.”). Thus, rather than disclosing a portal computer that sends
`
`edge connection requests to members of a network, Obraczka’s group master uses
`
`a top-down strategy of generating an entirely new topology and informing the
`
`other networked computers of the change.
`
`1. Obraczka in view of Denes and Shoubridge Fails to Disclose
`“a seeking [participant/node] [that] contacts a fully
`connected portal [computer/node]” (claims 1 and 14)
`
`Petitioner fails to identify any teaching in Obraczka that corresponds to “a
`
`seeking [participant/node] [that] contacts a fully connected portal
`
`[computer/node],” as recited in independent claims 1 and 14. In Petitioner’s
`
`discussion of this claim element, it misleadingly conflates two very distinct
`
`concepts from the Obraczka reference: a “group master,” which a member of a
`
`replica group that “is responsible for computing logical update topologies for the
`
`group” (see Obraczka at pg. 20, ¶ 4); and a “master,” which is a “participating
`
`process” in a “group of communicating processes” that communicate via the
`
`“Multicast Transport Protocol (MTP)” (see id. at pg. 91, ¶ 1). While the “master”
`
`supervises group membership and either accepts or rejects requests from a process
`
`that wants to join the group (see id. at pg. 91, ¶ 2), the same is not true for the
`
`- 15 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`“group master,” which is only distinguished from other group members because it
`
`is responsible for computing new topologies for the group:
`
`Any flood-d replica can perform topology calculations. Currently,
`a replica in a group is designated as the group master and is
`responsible for computing logical update topologies for the group.
`From time to time, the current group master collects cost estimates
`from replicas in its group and then computes the all-pairs shortest-
`paths between group members, generating a fully-connected cost
`matrix. Using this cost matrix and the group’s desired connectivity
`(typically 2 or 3), it computes a new logical update topology and, if
`the new topology is significantly better than the old, distributes it to
`all the group members.
`
`Id. at pg. 20, ¶ 4. Indeed, rather than a computer contacting Obraczka’s “group
`
`master,” which is the element that Petitioner alleges to be responsible for sending
`
`“an edge connection request” (see Petition at 29), Obraczka’s procedure for adding
`
`replicas to a group simply does not involve a new replica contacting the “group
`
`master:”
`
`Replicas may join or leave a replication group at any time. To join a
`group, a new replica copies a neighbor’s database, and floods its
`existence to the rest of the group. When a new member joins the
`group, a topology calculation is spawned. The resulting topology
`includes the new replica and is distributed to the group.
`
`Id. at pg. 20, ¶ 7.
`
`- 16 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`Petitioner provides no notice to the Board that these two elements, the
`
`“group master” and the “master,” are different entities from disparate technologies.
`
`Instead, Petitioner misleadingly implies that the “group master” and the “master”
`
`are interchangeable, and that the functionalities of one apply to the other, and vice
`
`versa. See Petition at 28 (relying on disclosures about both the “master” and
`
`“group master” to conclude that Obraczka teaches the claimed “fully connected
`
`portal computer”). Obraczka plainly teaches, however, that the “group master”
`
`and “master” are different components of different technologies—technologies that
`
`Obraczka finally concludes are incompatible—and Petitioner, contrary to the law,
`
`utterly fails to explain how or why the two concepts could or would be combined.
`
`See Unigene Labs., Inc. v. Apotex, Inc., 655 F.3d 1352, 1360 (Fed. Cir. 2011)
`
`(“Obviousness requires more than a mere showing that the prior art includes
`
`separate references covering each separate limitation in a claim under examination.
`
`…Rather, obviousness requires the additional showing that a person of ordinary
`
`skill at the time of the invention would have selected and combined those prior art
`
`elements in the normal course of research and development to yield the claimed
`
`invention.”) (emphasis added) (citations omitted).
`
`In fact, Obraczka concluded that such these two systems would not be
`
`combined at all, let alone in the manner (tacitly) envisioned in the Petition. As
`
`opposed to the group master, which is involved in Obraczka’s “flood-d” system
`
`- 17 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`for “perform[ing] topology calculations (see Obraczka at pg. 20, ¶ 4), the master is
`
`discussed in Obraczka’s chapter titled “Exploiting Internet Multicast,” which
`
`“presents the state-of-the-art of internet multicast architectures and multipoint
`
`transport protocols.” Id. at pg. 87, ¶ 1. In particular, the “master” is a component
`
`of the “Multicast Transport Protocol (“MTP”)—one of the “state-of-the-art internet
`
`multicast architectures—which purportedly “provides reliable and globally ordered
`
`delivery of client data among a group of communicating processes. Id. at pg. 91,
`
`¶ 2. Obraczka discusses the MTP in the context of determining “how the use of IP
`
`multicast can influence the performance of flood-d” (see id. at pg. 87, ¶ 2), but
`
`ultimately concludes that “most multipoint transport protocols are not well-suited
`
`for weakly consistent applications” (like flood-d):
`
`In this chapter, we overviewed existing and new in tern et
`multicasting architectures and multipoint transport protocols. We
`argue that most existing multipoint transport protocols are not well-
`suited for weakly consistent applications. Like the Real-Time
`Transport Protocol (RTP), they are either unreliable, or like the
`Reliable Broadcast Protocol (RBP), the Multicast Transport
`Protocol (MTP), and the Reliable Multicast Protocol (RMP), they
`provide strong consistency at the expense of latency and overhead.
`
`Id. at 109, ¶ 3.
`
`Petitioner asks the Board to combine elements from various, incompatible
`
`technologies discussed in the Obraczka reference without explaining how or why a
`
`- 18 -
`
`
`
`Patent Owner’s Preliminary Response
`IPR2016-00726 (U.S. Patent No. 6,910,069)
`
`person of ordinary skill in the art would have implemented MTP’s master in the
`
`context of Obraczka’s flood-d, particularly when Obraczka concludes that MTP is
`
`not well-suited for the task at hand. See id. Petitioner has not, therefore, explained
`
`“which combination(s) of elements in specific references would yield a predictable
`
`result, or how any specific combination would operate or read on the asserted
`
`claims.” ActiveVideo Networks, Inc., v. Verizon Communications, Inc., 694 F.3d
`
`1312, 1327 (Fed. Cir. 2012).
`
`For at least the foregoing reasons, Petitioner has not established a reasonable
`
`likelihood that Obraczka, Denes, and Shoubridge renders obvious independent
`
`claims 1 and 14 of the ‘069 Patent. Patent Owner respectfully requests, therefore,
`
`that the Board decline to institute trial on Petitioner’s proposed Ground 1.
`
`2. Obraczka in view of Denes and Shoubridge Fails to Disclose
`“a fully connected portal [computer/node] which in