throbber
Trials@uspto.gov
`571-272-7822
`
`
`
`
`Paper 8
`Entered: April 30, 2019
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`JUNIPER NETWORKS, INC.,
`Petitioner,
`
`v.
`
`PARITY NETWORKS, LLC,
`Patent Owner.
`____________
`
`Case IPR2018-01643
`Patent 6,831,891 B1
`____________
`
`
`Before JEFFREY S. SMITH, MIRIAM L. QUINN, and
`KAMRAN JIVANI, Administrative Patent Judges.
`
`SMITH, Administrative Patent Judge.
`
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`
`I. INTRODUCTION
`
`Petitioner filed a Petition for inter partes review of claims 1–6 of U.S.
`
`Patent No. 6,831,891 B1 (Ex. 1001, “the ’891 patent”). Paper 1 (“Pet.”).
`
`Patent Owner filed a Preliminary Response. Paper 7 (“Prelim. Resp.”).
`
`Institution of an inter partes review may not be authorized by statute “unless
`
`. . . 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).
`
`Upon consideration of the Petition and the Preliminary Response, we
`
`determine Petitioner has failed to demonstrated a reasonable likelihood that
`
`it would prevail in establishing the unpatentability of any of claims 1–6 of
`
`the ’891 patent. Accordingly, we do not institute the requested inter partes
`
`review.
`
`A. Related Matters
`
`The ’891 patent is the parent of US Patent No. 7,719,963 B2, which is
`
`the subject of IPR2018-01644.
`
`The ’891 patent is at issue in Parity Networks, LLC v. Juniper
`
`Networks, Inc., Case No. 6:17-cv-00495-RWS-KNM (E.D. Tex.). Pet. 1;
`
`Paper 4.
`
`B. The ’891 Patent
`
`The ’891 patent is directed to routing packets through alternative
`
`paths between nodes in a routing fabric, and in particular, to methods by
`
`which back-ups in a fabric may be avoided. Ex. 1001, 1:5–8. Figure 2 of
`
`the ’891 patent is reproduced below.
`
`2
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`
`Figure 2 above shows a diagram of fabric card 201 with nine external
`
`ports 205. Ex. 1001, 3:18–19. There are nine queue managers 209, one for
`
`each external port 205, with each queue manager isolated from its connected
`
`port by optical interface 207. Id. at 3:31–34. Queue managers interface
`
`with crossbar 203, which connects each port with the other eight ports. Id. at
`
`
`
`3:37–40.
`
`Each queue manager comprises a set of virtual output queues (VOQ),
`
`with individual VOQs associated with individual ones of the available
`
`outputs on a fabric card. Id. at 3:52–57. Data traffic coming in on any one
`
`port is directed to a queue associated with an output port. Id. at 3:59–62.
`
`3
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`Each queue manager on a fabric card has an ability to begin to drop packets
`
`at a predetermined rate at some threshold in queue capacity short of a full
`
`queue. Id. at 4:8–11. The queue manager may accelerate the rate of packet
`
`dropping as a queue continues to fill above the first threshold. Id. at 4:11–
`
`14. The queue manager is enabled to discard all incoming packets when the
`
`queue to which the packet is directed is full. Id. at 3:61–62, 4:16–17.
`
`C. Illustrative Claim
`
`Claims 1, 3, and 5 of the challenged claims of the ’891 patent are
`
`independent. Claim 1 is illustrative of the claimed subject matter:
`
`1. A method for managing data traffic at switching
`element nodes in a fabric network, each switching element node
`having a plurality of input and output ports, comprising the steps
`of:
`
`(a) establishing at each input port, a number of virtual
`output queues equal to the number of output ports, each virtual
`output queue at each individual input port dedicated to an
`individual output port, storing only packets destined for the
`associated output port, for managing incoming data traffic; and
`
`(b) accepting or discarding data at each virtual output
`queue directed to a queue according to a quantity of data in the
`queue relative to queue capacity by providing a queue manager
`for monitoring quantity of queued data in relation to a preset
`threshold, and discarding data from each virtual output queue at
`a predetermined rate, when the quantity of queued data reaches
`or exceeds the threshold;
`
`wherein in step (b), the queue manager increases the rate
`of discarding as quantity of queued data increases above the
`preset threshold, discarding all data traffic when the queue is full.
`
`Ex. 1001, 4:34–56.
`
`4
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`
`D. Evidence
`
`Petitioner relies on the following references. Pet. 17.
`
`Reference
`
`Int’l Publ./Appl. No.
`
`Date
`
`Ex. No.
`
`Schwartz
`
`WO 00/02347
`
`Jan. 13, 2000 Ex. 1004
`
`Muller
`
`Firoiu
`
`WO 00/52882
`
`Sept. 8, 2000
`
`Ex. 1005
`
`CA 2,310,531 A1
`
`July 10, 2001 Ex. 1006
`
`Petitioner also relies on the Declaration of Dr. Nicholas Bambos,
`
`dated August 31, 2018 (Ex. 1002), in support of its arguments.
`
`E. Asserted Grounds of Unpatentability
`
`
`
`Petitioner contends that claims 1–6 of the ’891 patent are unpatentable
`
`based on the following specific grounds:
`
`References
`
`Basis
`
`Challenged Claims
`
`Schwartz and Muller
`
`Firoiu and Muller
`
`
`
`§ 103(a)
`
`§ 103(a)
`
`1–6
`
`1–6
`
`II. DISCUSSION
`
`A. Relevant Law
`
`1. Obviousness
`
`A claim is unpatentable under 35 U.S.C. § 103(a) if the differences
`
`between the claimed subject matter 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 said subject matter
`
`pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). The
`
`question of obviousness is resolved on the basis of underlying factual
`
`determinations including: (1) the scope and content of the prior art; (2) any
`
`differences between the claimed subject matter and the prior art; (3) the level
`
`5
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`of skill in the art; and, (4) where in evidence, objective indicia of non-
`
`obviousness (i.e., so-called secondary considerations), including commercial
`
`success, long-felt but unsolved needs, failure of others, and unexpected
`
`results.1 Graham v. John Deere Co., 383 U.S. 1, 1718 (1966) (“the
`
`Graham factors”).
`
`2. Level of Skill
`
`The level of ordinary skill in the art usually is evidenced by the
`
`references themselves. See Okajima v. Bourdeau, 261 F.3d 1350, 1355
`
`(Fed. Cir. 2001); In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995); In
`
`re Oelrich, 579 F.2d 86, 91 (CCPA 1978). For an obviousness analysis,
`
`prior art references must be “considered together with the knowledge of one
`
`of ordinary skill in the pertinent art.” In re Paulsen, 30 F.3d 1475, 1480
`
`(Fed. Cir. 1994) (quoting In re Samour, 571 F.2d 559, 562 (CCPA 1978)).
`
`Petitioner asserts a person of ordinary skill in the art of the subject
`
`matter of the ’891 patent would have had a bachelor’s degree in computer
`
`science or electrical engineering or computer engineering or a related field
`
`plus either a master’s degree in such a field or two years of work or research
`
`experience in networking and computing. Pet. 16–17 (citing Ex. 1002 ¶ 31).
`
`Patent Owner does not oppose Petitioner’s proposed definition of a person of
`
`ordinary skill. Prelim. Resp. 10–11. We adopt Petitioner’s articulation of
`
`the level of skill in the art
`
`B. 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
`
`
`1 Patent Owner does not put forth evidence it alleges tends to show objective
`indicia of non-obviousness in its Preliminary Response.
`
`6
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`specification of the patent in which they appear. 37 C.F.R. § 42.100(b)
`
`(2017).2 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).
`
`At this stage, we determine that it is not necessary to provide an
`
`express construction of any term of the claims. Vivid Techs., Inc. v. Am. Sci.
`
`& Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (only terms that are in
`
`controversy need to be construed, and only to the extent necessary to resolve
`
`the controversy).
`
`C. Asserted Obviousness Over Schwartz and Muller
`
`Petitioner challenges claims 1–6 as obvious over Schwartz and
`
`Muller. Pet. 25–47.
`
`1. Schwartz (Ex. 1004)
`
`Schwartz is directed to the field of digital communications, and more
`
`particularly to systems and methods for switching packets of digital data in a
`
`switching node used in a digital data network. Ex. 1004, 1:5–7. Schwartz
`
`provides a switching node, including a plurality of input port modules, a
`
`plurality of output port modules and a switching fabric for transferring
`
`packets in a network. Id. at 3:14–17. Each input port module, upon
`
`receiving a packet, buffers the packet and generates a meta-data packet for
`
`
`2 A recent amendment to this rule does not apply here because the Petition
`was filed before November 13, 2018. See Changes to the Claim
`Construction Standard for Interpreting Claims in Trial Proceedings Before
`the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018) (to
`be codified at 37 C.F.R. pt. 42).
`
`7
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`the packet. Id. at 3:19–24. The meta-data packet includes information
`
`identifying the output port module that is to transmit the packet, the input
`
`port module in which the packet is buffered, and a pointer to the location in
`
`the input port module in which the packet is buffered. Id.
`
`A packet meta-data processor portion of the switching fabric receives
`
`meta-data packets from the input port modules, and also receives operational
`
`status information from each output port module. Id. at 3:25–30. The
`
`operational status information indicates an output port module’s buffering
`
`capacity to receive additional packets for transmission. Id. at 10:6–17. For
`
`each output port module, a corresponding packet meta-data processor
`
`processes the meta-data packets received from the input port modules using
`
`the operational status information from the output port module. Id. at 4:3–5.
`
`If the packet meta-data processor determines that the packet associated with
`
`the meta-data packet is to be dropped, it will notify the input port module
`
`where the packet is buffered, which, in turn, will discard the packet. Id. at
`
`4:5–8. If the packet meta-data processor determines that the packet
`
`associated with the meta-data packet is not to be dropped, it will enqueue the
`
`meta-data packet for the associated output port module. Id. at 4:8–10.
`
`2. Muller (Ex. 1005)
`
`Muller relates to a Network Interface Circuit (NIC) for processing
`
`communication packets exchanged between a computer network and a host
`
`computer system. Ex. 1005, 1:6–8. Muller discloses that the rate at which
`
`packets are transferred from a network interface circuit to a host computer or
`
`other communication device may fail to keep pace with the rate of packet
`
`arrival at the network interface. Id. at 3:30–32. If the host computer is
`
`unable to accept packets with sufficient alacrity, one or more packets may be
`
`8
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`dropped or discarded. Id. at 3:32–4:1. Muller discloses that, unless the
`
`dropping of packets is performed in a manner that distributes the effect
`
`among many network connections, network traffic may be degraded more
`
`than necessary. Id. at 4:8–14. Muller provides a system and method of
`
`discarding packets in a random manner, such that the effect of lost packets is
`
`evenly distributed among network communicants. Id. at 4:17–22.
`
`3. Analysis
`
`Claim 1 recites “(a) establishing at each input port, a number of
`
`virtual output queues equal to the number of output ports, each virtual output
`
`queue at each individual input port dedicated to an individual output port,
`
`storing only packets destined for the associated output port, for managing
`
`incoming data traffic.” Independent claims 3 and 5 recite a similar
`
`limitation.
`
`Petitioner contends Schwartz discloses this limitation by quoting
`
`passages from Schwartz that discuss a meta-data packet processor
`
`facilitating packet transfers from an input port module to an output port
`
`module. Pet. 29–31. For example, Petitioner contends Schwartz describes
`
`that for “each output port module, the packet meta-data processor processes
`
`the meta-data packets received from all of the input port modules in
`
`connection with the operational status information.” Pet. 30 (citing
`
`Ex. 1004, 4:3–10).
`
`Patent Owner contends that Schwartz does not teach establishing a
`
`number of virtual output queues at each individual input port as claimed.
`
`Prelim. Resp. 17. Specifically, Patent Owner contends Schwartz teaches
`
`that “only N buffers, or queues, are needed, one for each input port module,
`
`whereas in an output-queued switching node N2 buffers would be required.”
`
`9
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`Id. (quoting Ex. 1004, 4:23–29).
`
`We are persuaded by Patent Owner’s argument. Petitioner contends
`
`that Schwartz discloses “establishing at each input port, a number of virtual
`
`output queues” by quoting sections of Schwartz that do not explicitly teach
`
`establishing virtual output queues at each input queue. See Pet. 28–31.
`
`After quoting Schwartz, Petitioner concludes “[a] person of ordinary skill in
`
`the art would have recognized from the above-identified disclosures that
`
`Schwartz discloses” the claimed “establishing, at each input port, a number
`
`of virtual output ports.” Pet. 31. Dr. Bambos provides similar conclusory
`
`testimony for this limitation. Ex. 1002 ¶¶ 75–80. Neither the Petition nor
`
`the testimony of Dr. Bambos explains how the quoted sections of Schwartz
`
`teach (1) a number of virtual output ports, or (2) that such virtual output
`
`ports are established at each input port.
`
`The sections of Schwartz quoted in the Petition discuss packet meta-
`
`data processors that determine whether to transfer or drop packets located in
`
`input port modules, but the Petition does not map the claimed virtual output
`
`queues to the packet meta-data processors. See Pet. 29–31. Even if we were
`
`to map the claimed virtual output queues to the packet meta-data processors,
`
`Petitioner does not explain how the packet meta-data processors, which are
`
`located in the switch fabric (Ex. 1004, 3:25–26), teach establishing the
`
`virtual output queues “at each input port” as claimed. Petitioner also does
`
`not explain how the packet meta-data processors, which store meta-data
`
`(Ex. 1004, 4:8–10, 18:14–16), teach “each virtual output queue . . . storing
`
`only packets” as claimed.
`
`Finally, the Petition itself quotes Schwartz’s disclosure that “only ‘N’
`
`buffers, or queues, are needed, one for each input port module, whereas in an
`
`10
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`output-queued switching node N2 buffers would be required.” Pet. 21
`
`(quoting Ex. 1004, 4:23–29); see also Ex. 1004, 2:22 (“Only one queue is
`
`needed for each input port”). However, Petitioner does not explain how
`
`Schwartz’s disclosure of “one [queue] for each input port module” teaches
`
`“establishing at each input port, a number of virtual output queues equal to
`
`the number of output ports” as claimed.
`
`Petitioner does not sufficiently show that Schwartz teaches
`
`“establishing at each input port, a number of virtual output queues equal to
`
`the number of output ports, each virtual output queue at each individual
`
`input port dedicated to an individual output port, storing only packets
`
`destined for the associated output port, for managing incoming data traffic”
`
`as claimed. Petitioner does not contend that Muller teaches this limitation.
`
`On the record before us, we determine that the Petition and supporting
`
`evidence do not adequately establish a reasonable likelihood that Petitioner
`
`would prevail on its assertion that the combination of Schwartz and Muller
`
`renders independent claims 1, 3, or 5, or dependent claims 2, 4, or 6,
`
`obvious.
`
`D. Asserted Obviousness Over Firoiu and Muller
`
`Petitioner challenges claims 1–6 as obvious over Firoiu and Muller.
`
`Pet. 47–61.
`
`1. Firoiu (Ex. 1006)
`
`Firoiu relates to the management of a queue at a node in a network.
`
`Ex. 1006, 1:12–14. Firoiu teaches that to prevent buffer overflow, the buffer
`
`of each node is regulated by a node congestion control module that regulates
`
`the average queue size by indicating to the sending node that congestion is
`
`11
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`occurring at the receiving node. Id. at 4:34–5:1. The system then decreases
`
`the sending rate at the sending node. Id. at 5:3–9.
`
`2. Analysis
`
`Claim 1 recites “establishing at each input port, a number of virtual
`
`output queues equal to the number of output ports, each virtual output queue
`
`at each individual input port dedicated to an individual output port, storing
`
`only packets destined for the associated output port, for managing incoming
`
`data traffic.” Petitioner quotes passages of Firoiu that disclose queuing
`
`packets in a buffer of an ingress port of a node, and regulating the buffer
`
`using a node congestion control module. See Pet. 49. Petitioner then
`
`concludes that a “person of ordinary skill in the art would have recognized
`
`from the above-identified disclosures that Firoiu” teaches the claimed
`
`“establishing at each input port, a number of virtual output queues equal to
`
`the number of output ports.” Id.
`
`The sections of Firoiu quoted in the Petition discuss a buffer for an
`
`ingress port of a node, and also a node congestion control module to prevent
`
`congestion at the node. See Pet. 49. However, the Petition does not explain
`
`how the buffer for the ingress port of Firoiu teaches “establishing at each
`
`input port, a number of virtual output queues” as claimed. The Petition also
`
`does not explain how the node congestion control module teaches
`
`“establishing at each input port, a number of virtual output queues” as
`
`claimed.
`
`Petitioner does not sufficiently show that Firoiu teaches “establishing
`
`at each input port, a number of virtual output queues equal to the number of
`
`output ports, each virtual output queue at each individual input port
`
`dedicated to an individual output port, storing only packets destined for the
`
`12
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`associated output port, for managing incoming data traffic” as claimed.
`
`Petitioner does not contend that Muller teaches this limitation. On the
`
`record before us, we determine the Petition and supporting evidence do not
`
`adequately establish a reasonable likelihood that Petitioner would prevail on
`
`its assertion that the combination of Firoiu and Muller renders independent
`
`claims 1, 3, or 5, or dependent claims 2, 4, or 6, obvious.
`
`
`
`III. CONCLUSION
`
`
`
`For the foregoing reasons, we determine that the information
`
`presented in the Petition does not establish that there is a reasonable
`
`likelihood that Petitioner would prevail with respect to claims 1–6 of the
`
`’891 patent.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IV. ORDER
`
`Accordingly, it is
`
`ORDERED that the Petition is denied.
`
`
`
`13
`
`

`

`IPR2018-01643
`Patent 6,831,891 B1
`
`PETITIONER:
`
`Sasha Rao
`srao@maynardcooper.com
`
`John Hintz
`jhintz@maynardcooper.com
`
`John Hanish
`jhanish@maynardcooper.com
`
`Brandon Stoy
`bstoy@maynardcooper.com
`
`
`PATENT OWNER:
`
`Gregory S. Donahue
`gdonahue@dpelaw.com
`
`Douglas Bridges
`bridges@capitallegalgroup.com
`
`
`14
`
`

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