throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket