throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`BUNGIE, INC.
`Petitioner,
`
`v.
`
`ACCELERATION BAY, LLC,
`Patent Owner.
`
`
`
`Case IPR2017-01600
`Patent 6,910,069 B1
`
`
`Before SALLY C. MEDLEY, MARC S. HOFF, and
` LYNNE E. PETTIGREW, Administrative Patent Judges.
`
`HOFF, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`Trials@uspto.gov
`571-272-7822
`
`
`
`
`Paper 11
` Entered: January 10, 2018
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`
`I. INTRODUCTION
`Bungie, Inc. (“Petitioner”) filed a Petition for inter partes review of
`
`claims 1–5, 7, 8, and 11–13 of U.S. Patent No. 6,910,069 B1 (Ex. 1001, “the
`’069 patent”). Paper 2 (“Pet.”). Acceleration Bay, LLC (“Patent Owner”)
`filed a Preliminary Response. Paper 6 (“Prelim. Resp.”). Petitioner filed a
`Reply to the Preliminary Response. Paper 10 (“Reply”).
`Institution of an inter partes review is authorized by statute when “the
`information presented in the petition . . . and any response . . . shows that
`there is a reasonable likelihood that the petitioner would prevail with respect
`to at least 1 of the claims challenged in the petition.” 35 U.S.C. § 314(a); see
`37 C.F.R. § 42.108. Upon consideration of the Petition and Preliminary
`Response, we conclude the information presented does not show there is a
`reasonable likelihood that Petitioner would prevail in establishing the
`unpatentability of any of claims 1–5, 7, 8, and 11–13 of the ’069 patent.
`
`A. Related Matters
`The parties identify the following pending judicial matters as relating
`to the ’069 patent: Acceleration Bay LLC v. Activision Blizzard, Inc., Case
`No. 1:16-cv-00453 (D. Del., filed June 17, 2016); Acceleration Bay LLC v.
`Electronic Arts Inc., Case No. 1:16-cv-00454 (D. Del., filed June 17, 2016);
`Acceleration Bay LLC v. Take-Two Interactive Software, Inc., Case No.
`1:16-cv-00455 (D. Del., filed June 17, 2016). Pet. 28; Paper 3, 1.
`Claims 1–17 of the ’069 patent were challenged previously by
`different petitioners in IPR2016-00726. The Board denied institution in
`that proceeding. IPR2016-00726, Paper 11 (PTAB Sept. 9, 2016).
`

`
`2
`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`B. The ’069 Patent
`The ’069 patent relates to a “broadcast technique in which a broadcast
`channel overlays a point-to-point communications network.” Ex. 1001, 4:5–
`6. The communication network consists of a graph of point-to-point
`connections between host computers or nodes. Id. at 4:25–28. Figure 1 of
`the ’069 patent is reproduced below:

`
`
`
`Figure 1 illustrates a broadcast channel represented by a “4-regular
`and 4-connected” graph. Id. at 4:50–51. The graph of Figure 1 is “4-
`regular” because each node is connected to exactly four other nodes (e.g.,
`node A is connected to nodes E, F, G, and H). Id. at 4:40–41, 4:51–55. A
`node in a 4-regular graph can only be disconnected if all four of the
`connections to its neighbors fail. Id. at 4:65-5:1. Moreover, the graph of
`3
`
`
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`Figure 1 is “4-connected” because it would take the failure of four nodes to
`divide the graph into two separate sub-graphs (i.e., two broadcast
`channels). Id. at 5:1-5. To connect to the broadcast channel, a seeking
`computer locates a computer that is connected to the broadcast channel and
`then establishes a connection with a number of computers connected to the
`broadcast channel. Id. at Abstract.
`Figures 3A and 3B of the ’069 patent are reproduced below.
`
`
`
`Figures 3A and 3B illustrate a process of connecting a new computer
`Z to the broadcast channel. Id. at 2:51–52. Figure 3A illustrates the
`broadcast channel of a 4-regular graph, where each of the computers is
`already connected to four computers. Id. at 5:55–57. Some of the
`connections between computers need to be broken so that the seeking
`computer can connect to four computers. In one embodiment, two pairs of
`computers that are connected to each other are identified. Id. at 5:57–61.
`Each of these pairs breaks the connection between them, and then each of
`the four computers (two from each pair) connects to the seeking computer.
`Id. at 5:61–64. The above figures show this concept, illustrating seeking
`4
`
`
`
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`computer Z connecting to the broadcast channel. Computers B and E and
`computers C and D are the two identified pairs of computers that are
`identified as neighbors for new computer Z. Id. at 5:67–6:2. The
`connection between each of these pairs is broken, and a connection between
`computer Z and each of computers B, C, D, and E is established. Id. at 6:2–
`6:5.
`
`C. Illustrative Claim
`Petitioner challenges claims 1–5, 7, 8, and 11–13. Independent claim
`1 is illustrative of the claimed subject matter:
`1. A computer-based, non-routing table based, non-switch
`based method for adding a participant to a network of
`participants, each participant being connected to three or more
`other participants, the method comprising:
`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;
`disconnecting the participants of the identified pair from
`each other; and
`connecting each participant of the identified pair of
`participants to the seeking participant.
`Ex. 1001, 28:48–62.
`
`5
`
`
`
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`D. Asserted Ground of Unpatentability
`Petitioner asserts that claims 1–5, 7, 8, and 11–13 are unpatentable
`based on the following ground (Pet. 32):
`References
`Francis1 and Gilbert2
`
`Challenged Claims
`1–5, 7, 8, and 11–13
`
`Basis
`§ 103(a)
`
`
`
`
`
`
`II. DISCUSSION
`
`A. Claim Construction
`In an inter partes review, we construe claim terms in an unexpired
`patent according to their broadest reasonable construction in light of the
`specification of the patent in which they appear. 37 C.F.R. § 42.100(b);
`Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–46 (2016)
`(upholding the use of the broadest reasonable interpretation standard).
`Consistent with the broadest reasonable construction, claim terms are
`presumed to have their ordinary and customary meaning as understood by a
`person of ordinary skill in the art in the context of the entire patent disclosure.
`In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007).
`Our decision does not turn on Petitioner’s or Patent Owner’s proposed
`construction of “fully connected.” See Pet. 34–36; Prelim. Resp. 11–15.
`Therefore, we determine that no claim terms require express construction, and
`
`                                                            
`1 Paul Francis, Yallcast: Extending the Internet Multicast Architecture, NTT
`Information Sharing Platform Laboratories (Sept. 30, 1999) (Ex. 1005)
`(“Francis”).
`2 U.S. Patent No. 6,490,247 B1, filed June 26, 1996, issued Dec. 3, 2002
`(Ex. 1021) (“Gilbert”).
`
`6
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`we express no opinion regarding Petitioner’s or Patent Owner’s proposed
`construction.
`
`B. Asserted Obviousness over Francis and Gilbert
`Petitioner contends that independent claim 1 is unpatentable under 35
`U.S.C. § 103(a) as obvious over Francis and Gilbert, and that the remaining
`challenged claims that depend from claim 1 would have been obvious over the
`same art. Pet. 36–65. Relying on the testimony of Dr. Nicholas Bambos,
`Petitioner explains how the combined prior art allegedly teaches or suggests
`all of the claim limitations. Id. (citing Ex. 1003).
`
`Summary of Francis
`Francis describes an architecture for so-called “yallcast” multicasting
`that attempts to unify prior server-based and IP multicast approaches. Ex.
`1005, 2. Yallcast features a topology management protocol (YTMP) that
`allows a group of hosts to dynamically auto-configure into two topologies:
`(1) a tunneled, shared tree topology for efficient multicast distribution of
`application content; and (2) a tunneled mesh topology, for robust broadcast
`distribution of various information, including control information and,
`where appropriate, application content. Id. at 5. Each group has one or
`more rendezvous hosts associated with it. Rendezvous hosts are not
`attached to the tree-mesh – rather, they serve as a discovery or bootstrap
`

`
`7
`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`mechanism for allowing hosts joining a group to find other hosts already in
`the tree-mesh. Id.
`
`Summary of Gilbert
`
`Gilbert describes a ring-ordered dynamically reconfigurable computer
`
`network utilizing an existing communications system. Ex. 1021, Abstract.
`Each node is coupled to the existing communications system by two data
`channels and a control channel. Id. Gilbert’s network includes a network
`manager to establish the network, facilitate communication among the nodes,
`and dynamically reconfigure the network without disturbing communication
`among the nodes. Id. 
`
`Analysis
`Based on the record before us, we determine that there is not a
`reasonable likelihood that Petitioner will prevail in showing that any of
`claims 1–5, 7, 8, and 11–13 are unpatentable on the grounds asserted.
`Claim 1 requires a participant seeking to join the network to contact “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. Petitioner relies on Gilbert and
`Francis for different aspects of this limitation. First, Petitioner cites to
`Gilbert for disclosure of a portal computer sending a “connection request” to
`nodes existing on the network for the joining node. Pet. 51. In particular,
`Petitioner cites Gilbert’s disclosure of “two adjacent nodes dropping
`connection to one another” in favor of each establishing connections to the
`joining node. Id. (citing Ex. 1021, 7:10–19). In that example, according to
`Petitioner, Gilbert discloses that the connections may be initiated by one of
`8
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`each adjacent node pair, not by the joining node. Id. (citing Ex. 1021, 7:19–
`20).
`
`Patent Owner argues, and we agree, that Petitioner admits that the
`“portal computer” of Gilbert never sends an edge connection request to a
`number of neighboring participants because the alleged portal computer is
`one of the nodes to which the additional node is to connect. Prelim. Resp.
`56–57 (citing Pet. 52 (“Gilbert discloses a node in an adjacent node pair
`functioning as a portal computer.”)). We agree with Patent Owner, because
`Gilbert discloses that the joining (“additional”) node “first contacts a
`[single] node it knows to be already connected on the network.” Ex. 1021,
`6:33–34. That “known” node then “provides information [to the joining
`node] regarding an adjacent node to the additional node.” Ex. 1021, 6:40–
`42. Gilbert thus discloses that a portal computer sends a connection request
`to at most one “neighboring” participant.
`Petitioner contends that Gilbert’s disclosed “alternative embodiment,”
`in which “the step of contacting two adjacent nodes . . . can be ‘executed by
`a joinder module within the network manager,’” meets the claim language
`concerning an edge connection request to a number of [randomly selected]
`neighboring participants. Pet. 52. We agree with Patent Owner that
`Petitioner’s contention mischaracterizes Gilbert’s disclosure, because
`Gilbert’s network manager is a functional component that is included within
`one or more nodes, including a node that wishes to join an existing network,
`rather than being a so-called “master node.” Prelim. Resp. 57. Gilbert
`discloses a network manager that is “contained within each node such that
`the nodes communicate in a peer-to-peer manner. Ex. 1021, 3:64–65. “In a
`

`
`9
`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`further embodiment, a port controller runs on each computer to perform the
`network manager function.” Ex. 1021, 3:65–67.
`Patent Owner further argues that no computer in Gilbert ever sends
`edge connection requests to any neighboring participants, let alone
`neighboring participants that have been randomly selected. Prelim. Resp.
`58. As Patent Owner explains, “[t]he additional node connects with each of
`the adjacent nodes, in the same manner as node N connects to node N+1 in
`step 48 of Figure 4.” Prelim. Resp. 58 (quoting Ex. 1021, 7:13–16). Once
`the additional node has unique address information for the two nodes, the
`switch causes a connection to be made. Prelim. Resp. 58 (citing Ex. 1021,
`4:57–67). Patent Owner contends, therefore, that there is no disclosure in
`Gilbert of a portal computer sending an edge connection request to
`neighboring participants because the switch is responsible for making
`connections. Id. We agree with Patent Owner.
`Petitioner concedes that Gilbert does not disclose sending a request to
`a number of randomly selected neighboring participants to which the
`seeking participant is to connect. Pet. 55. Petitioner cites to Francis for
`disclosure of ‘randomly selected’ nodes existing on the network.
`“[E]ach member M establishes a small number of other members
`– three or four – as mesh neighbors. These members are randomly
`selected . . . . [M]esh neighbors are randomly chosen . . . .
`Efficient random selection is achieved through a frame delivery
`mode called ‘mesh anycast’, whereby a discovery message takes a
`random walk along the mesh, randomly stopping at some
`member.”
`
`Pet. 51 (citing Ex. 1005, 14). Petitioner admits that no attempt is made to
`find mesh neighbors that are nearby (latency-wise). Ex. 1005, 14; see Pet.
`

`
`10
`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`55. “YDP anycast simply causes a frame to randomly walk the tree or mesh
`until it (randomly) decides to stop (or the hop count expires). Anycast is
`used by the Yallcast Tree Management Protocol (YTMP) for discoverying
`[sic] arbitrary members in the topology.” Ex. 1005, 17.
`Petitioner argues that “Francis provides for random selection of
`neighbors for every node, which necessarily includes a joining node, by
`performing a ‘random walk along the mesh.’” Pet. 55. Both the route’s path
`and its length are random. Id. According to Petitioner, “this type of
`selection – a ‘random walk’ – is the same type of random selection
`described in the ’069 Patent.” Pet. 55; Ex. 1001, 13:41–45 (“This sending of
`the [connection request] message corresponds to a random walk through the
`graph that represents the broadcast channel. Eventually, a receiving
`computer will decide that the message has traveled far enough to represent a
`randomly selected computer.”).
`Petitioner, however, has not sufficiently explained how or why a
`person having ordinary skill in the art would have combined Francis and
`Gilbert to achieve this claim element. Petitioner explains that Francis
`teaches rendezvous hosts that allow hosts joining a group to find other
`hosts already in the tree-mesh, and that Francis randomly selects
`“neighbors” (simply other network members) for every node. See Pet. 53–
`55. Petitioner further argues that Gilbert, like Francis, teaches the concept
`of multifunctional nodes that can execute the steps of adding a new node to
`the network. According to Petitioner, modifying Francis’s rendezvous host
`with the features of Gilbert’s portal computer would provide some
`messaging efficiencies. Pet. 55. In our view, however, Petitioner fails to
`explain sufficiently why it would have been obvious to combine Francis
`11
`

`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`and Gilbert to have a seeking participant contact a fully connected portal
`computer as claimed.
`Still further, the disputed phrase requires that the edge connection
`request be sent to a “number of randomly selected” neighboring
`participants to which the seeking participant is to connect. Petitioner asserts
`that Francis provides for random selection of neighbors for every node. Pet.
`55; Ex. 1005, 14. Merely choosing neighboring participants in a random
`manner to connect to, as Francis does here, is not the same as sending a
`request to a number of randomly selected neighboring participants.
`Petitioner has not explained how Francis and Gilbert would be combined to
`teach a portal computer “send[ing] an edge connection request to a number
`of randomly selected neighboring participants.”
`For all of the above reasons, we are not persuaded that Petitioner has
`established a reasonable likelihood that Petitioner would prevail in its
`challenge to independent claim 1, or to dependent claims 2–5, 7, 8, and
`11–13.
`
`B. Motion to Seal
`Patent Owner’s Preliminary Response (Paper 6) was accompanied by a
`Motion to Seal (Paper 7) its Preliminary Response and Exhibits 2004–2010,
`along with a redacted version of the Preliminary Response and redacted
`versions of Exhibits 2006–2010. As we do not rely on the material that Patent
`Owner seeks to seal, we decline to address the merits of the Motion to Seal.
`Patent Owner is authorized to file a motion to expunge any material that it
`seeks to keep confidential within thirty (30) days of this decision, or within
`thirty (30) days of a decision on rehearing if rehearing is requested.
`

`
`12
`
`

`

`IPR2017-01600
`Patent 6,910,069 B1
`  
`
`
`III. CONCLUSION
`For the foregoing reasons, we determine that there is not a reasonable
`likelihood that Petitioner would prevail in showing that claims 1–5, 7, 8,
`and 11–13 of the ’069 patent are unpatentable.
`
`IV. ORDER
`For the foregoing reasons, it is
`ORDERED that the Petition is denied as to all challenged claims, and
`no trial is instituted.
`
`
`
`
`
`
`
`
`FOR PETITIONER:
`
`Michael T. Rosato
`Andrew S. Brown
`Eric C. Arnell
`WILSON SONSINI GOODRICH & ROSATI
`mrosato@wsgr.com
`asbrown@wsgr.com
`earnell@wsgr.com
`
`FOR PATENT OWNER:
`
`James Hannah
`Jeffrey H. Price
`KRAMER LEVIN NAFTALIS & FRANKEL LLP
`jhannah@kramerlevin.com
`jprice@kramerlevin.com
`

`
`13
`
`

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