UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`JUNIPER NETWORKS, INC.,
`Petitioner
`
`v.
`
`PARITY NETWORKS, LLC,
`Patent Owner
`
`Case No.: 2018-01643
`Patent No.: 6,831,891
`
`REQUEST FOR REHEARING
`PURSUANT TO 37 C.F.R. § 42.71(d)
`
`Mail Stop Inter Partes Review
`Patent Trial and Appeal Board
`United States Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`JUNIPER NETWORKS, INC.,
`Petitioner
`
`v.
`
`PARITY NETWORKS, LLC,
`Patent Owner
`
`Case No.: 2018-01643
`Patent No.: 6,831,891
`
`REQUEST FOR REHEARING
`PURSUANT TO 37 C.F.R. § 42.71(d)
`
`Mail Stop Inter Partes Review
`Patent Trial and Appeal Board
`United States Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`TABLE OF CONTENTS
`
`I.
`II.
`III.
`
`INTRODUCTION ........................................................................................... 1
`LEGAL STANDARDS ................................................................................... 2
`BASIS FOR RELIEF REQUESTED .............................................................. 2
`
`A.
`
`B.
`
`The “Virtual Output Queue” Limitations of the ’891 Patent ................ 3
`
`Schwartz Discloses “Virtual Output Queues” As Claimed ................... 3
`
`1. Failure to map virtual output queues to packet meta-data
`processors .............................................................................................. 4
`
`2. Failure to show virtual output queues “at each input port”................... 6
`
`3. Storing only packets .............................................................................. 8
`
`4. Virtual output queues equal to the number of output ports................. 10
`
`C.
`
`Summary – Claim Chart ...................................................................... 11
`
`IV. CONCLUSION .............................................................................................14
`
`i
`
`
`
`TABLE OF AUTHORITIES
`
`Cases
`
`Eli Lilly & Co. v. Bd. Of Regents of the Univ. of Wash.,
`
`334 F.3d 1264 (Fed. Cir. 2003) .............................................................................. 2
`
`Stevens v. Tamai,
`
`366 F.3d 1325 (Fed. Cir. 2004) .............................................................................. 2
`
`Statutes and Other Authorities
`
`37 C.F.R. § 42.100(b) ................................................................................................ 1
`
`37 C.F.R. § 42.71(c) ................................................................................................... 2
`
`37 C.F.R. § 42.71(d) .................................................................................................. 2
`
`ii
`
`
`
`Pursuant to 37 C.F.R. § 42.71(d), Petitioner Juniper Networks, Inc.
`
`(“Petitioner”) hereby submits this Request for Rehearing in response to the
`
`“Decision Denying Inter Partes Review” of U.S. Patent No. 6,831,891 (“the ’891
`
`patent”). (See Paper 8, “Decision”).
`
`I.
`
`INTRODUCTION
`
`The Board’s Decision denied institution on two grounds for review of the
`
`’891 patent based on 35 U.S.C. § 103(a): (1) the combination of WO 00/02347
`
`(“Schwartz”) and WO 00/52882 (“Muller”); and (2) the combination of
`
`CA 2,310,531 A1 (“Firoiu”) and Muller. Both grounds covered all claims (claims
`
`1-6) of the ’891 patent.
`
`Petitioner respectfully requests that the Board reconsider its Decision
`
`denying institution based on Ground 1, the combination of Schwartz and Muller,
`
`because the Board misapprehended Schwartz, overlooked petitioner’s arguments
`
`about Schwartz, and failed to construe claims of the ’891 patent according to the
`
`broadest reasonable interpretation in light of the specification in which they
`
`appear pursuant to 37 C.F.R. § 42.100(b).1 Instead, the Board improperly
`
`narrowed the scope of the claims of the ’891 patent to exclude invalidating prior
`
`1 As the Board is aware, 37 C.F.R. § 42.100(b) was amended, effective
`November 13, 2018, to require application of the same claim construction standard
`as used by District Courts (see 83 Fed. Reg. 51,340, 51,340-41 (October 11,
`2018)), but Petitioner filed the Petition at issue here before the effective date of
`that amendment, so the broadest reasonable interpretation standard applied to the
`Petition and applies to this Request for Rehearing.
`
`1
`
`
`
`art. This led to erroneous findings of fact with regard to whether certain claim
`
`elements were disclosed by Schwartz, as shown by the Petition.
`
`II.
`
`LEGAL STANDARDS
`
`A request for rehearing “must specifically identify all matters the party
`
`believes the Board misapprehended or overlooked, and the place where each
`
`matter was previously addressed in a motion, an opposition or reply.” 37 C.F.R.
`
`§ 42.71(d). “When rehearing a decision on a petition, the panel will review the
`
`decision for an abuse of discretion. 37 C.F.R. § 42.71(c). “An abuse of discretion
`
`occurs where the decision is (1) clearly unreasonable, arbitrary, or fanciful; (2) is
`
`based on an erroneous conclusion of law; (3) rests on clearly erroneous fact
`
`findings; or (4) involves a record that contains no evidence on which the Board
`
`could rationally base its decision.” Stevens v. Tamai, 366 F.3d 1325, 1329 (Fed.
`
`Cir. 2004) (quoting Eli Lilly & Co. v. Bd. Of Regents of the Univ. of Wash.,
`
`334 F.3d 1264, 1266-67 (Fed. Cir. 2003)).
`
`III. BASIS FOR RELIEF REQUESTED
`
`Petitioner requests reconsideration of the decision denying review of claims
`
`1-6 of the ’891 patent as obvious over the combination of Schwartz and Muller
`
`because the decision improperly limits the scope of the claimed “virtual output
`
`queues” in a way that excludes invalidating disclosures from the prior art
`
`references and excludes preferred embodiments of the ’891 patent, with the result
`
`2
`
`
`
`being that the Decision misapprehended the disclosures of Schwartz (and
`
`Petitioner’s arguments in the Petition) in finding that reference did not disclose
`
`claim limitations of the ’891 patent.
`
`A.
`
`The “Virtual Output Queue” Limitations of the ’891 Patent
`
`Claim 1 of the ’891 patent recites, among other things, “(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 input port dedicated to an individual
`
`output port, storing only packets destined for the associated output port, for
`
`managing incoming data traffic.” (See Decision at 4). As the Decision observes,
`
`independent claims 3 and 5 of the ’891 patent contain similar limitations.
`
`(Decision at 9).
`
`According to the ’891 patent, the claimed “virtual output queues” are within
`
`queue managers connected through an optical link to each external port.
`
`(Decision at 3 (citing Ex. 1001 at Fig. 2, 3:31-34, 37-40)). Figure 2 of the ’891
`
`patent shows the “queue managers” (element 209) and thus the “virtual output
`
`queues” therein, as being located at a distance from the input ports (element 205)
`
`to which they are associated. (See Ex. 1001 at Fig. 2, 3:31-40).
`
`B.
`
`Schwartz Discloses “Virtual Output Queues” As Claimed
`
`The Board’s Decision finds that Petitioner did not explain “how the quoted
`
`sections of Schwartz teach (1) a number of virtual output ports, or (2) that such
`
`3
`
`
`
`virtual output ports are established at each input port.” (Decision at 10).
`
`According to the Decision, the Board’s finding is based on four alleged failures of
`
`proof: (1) a failure to “map the claimed virtual output queues of to the packet
`
`meta-data processors of Schwartz;” (2) a failure to “explain how the packet meta-
`
`data processors, which are located in the switch fabric …, teach establishing the
`
`virtual output queues ‘at each input port’ as claimed; (3) a failure to explain “how
`
`the packet meta-processors, which store meta-data …, teach ‘each virtual output
`
`queue … storing only packets” as claimed; and (4) a failure to explain how
`
`Petitioner’s quotation of Schwartz – “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 …” – “teaches ‘establishing at each input port, a
`
`number of virtual output queues equal to the number of output ports,’ as claimed.”
`
`(Decision at 10-11).
`
`Respectfully, the Board erred by looking at the wrong element disclosed in
`
`Schwartz and by not giving the claims the broadest reasonable interpretation, and
`
`as a result, used a claim interpretation that does not cover a preferred embodiment
`
`of the ’891 patent. Petitioner addresses each of the Board’s four bases below.
`
`1.
`
`Failure to map virtual output queues
`to packet meta-data processors
`
`In reaching its first conclusion, that Petitioner failed to “map the claimed
`
`virtual output queues to the packet meta-data processors” of Schwartz (Decision at
`
`4
`
`
`
`10), the Board focused on the wrong thing. Petitioner did not argue that the
`
`claimed “virtual output queues” are Schwartz’s meta-data processors. Instead,
`
`Petitioner’s argument was and is that the claimed “virtual output queues” are
`
`disclosed in Schwartz as the combination of meta-data packets and the input
`
`buffers in which the packets are stored. (See Petition at 29-30 (“For ‘each input
`
`port module, upon receiving a packet from the communication link connected
`
`thereto, buffers the packet and generates a meta-data packet therefor, the meta-
`
`data packet identifying the output port module that is to transmit the packet, and
`
`generates identifier information for the packet, in particular the identification of
`
`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.’” (quoting
`
`Ex. 1004, Schwartz, 3:19-23)).
`
`As to the meta-data processor, Petitioner presented evidence that it is
`
`something different from the claimed “virtual output queue”: “The packet meta-
`
`data processor 23 of Schwartz is a ‘queue manager’ that monitors the amount of
`
`data at queues and adjust[s] the acceptance or discarding of data packets according
`
`to the status information ….” (Ex. 1002, Bambos Decl., ¶ 83). This also is
`
`evident from Petitioner’s evidence that showed the meta-data processor of
`
`Schwartz performs a different function than the claimed “virtual output queues”:
`
`5
`
`
`
`The packet meta-data processor processes the packets received from
`
`the input modules in connection with the operational status of the
`
`output modules. If the processor determines that the packet is to be
`
`dropped, “it will notify the input port module in which the packet is
`
`buffered, which, in turn, will discard the packet.” [Ex. 1001] at p. 4,
`
`ll. 3-8. If the processor determines that the packet is not to be
`
`dropped, “it will enqueue the meta-data packet for associated output
`
`port module.” Id. at ll. 8-10.
`
`(Ex. 1002, Bambos Decl., ¶ 58 (emphasis added)). There was no need for
`
`Petitioner to map the claimed “virtual output queues” to the packet meta-data
`
`processors of Schwartz because that is not the disclosure on which Petitioner
`
`relies. The Board erred in using this basis to deny the Petition, and Petitioner
`
`showed Schwartz discloses “virtual output queues.”
`
`2.
`
`Failure to show virtual output queues
`“at each input port”
`The Board was incorrect in faulting Petitioner for failing to “explain how
`
`the packet meta-data processors, which are located in the switch fabric …, teach
`
`establishing the virtual output queues ‘at each input port’ as claimed.” (Decision
`
`at 10 (emphasis added)).
`
`First, as explained above in Section III.B.1, it is the buffers located at the
`
`input port and the meta-data packets used therewith, as described above, that
`
`6
`
`
`
`disclose the claimed “virtual output queues.” Thus, Schwartz discloses that the
`
`claimed “virtual output queues” are “at” each input port. (See Petition at 29-30).
`
`This interpretation is further supported by Petitioner’s explanation of one
`
`mechanism disclosed in Schwartz. Specifically, after receiving a packet, each
`
`input module “buffers the packet and generates a meta-data packet therefor.”
`
`(Petition at 19 (citing Schwartz at 3:17-19)). As described above and in the
`
`Petition, the buffers and meta-data packets on Schwartz are analogous to the
`
`“virtual output queues” of the ’891 patent. (Petition at 29).
`
`Second, the broadest reasonable interpretation of the claimed “virtual output
`
`queues” being located “at each input port” must be made in light of the ’891
`
`patent’s description that “[e]ach queue manager comprises a set of virtual output
`
`queues (VOQs)” (Ex. 1001 at 3:54-55), also called “queue management gates”
`
`(id., 3:52-54), and the queue managers are “[i]n the fabric card” (id. at 3:31-34
`
`(emphasis added)). This description means that the claimed “virtual output
`
`queues” must necessarily be physically “at” each input port. This also is evident
`
`from Figure 2 of the ’891 patent that definitively shows the “queue managers”
`
`(element 209) located on the fabric card at a distance from the input ports
`
`(element 205):
`
`7
`
`
`
`(Ex. 1001, Fig. 2). The Board cited this same evidence, yet did not apply it
`
`correctly. See Decision at 3 (citing Ex. 1001 at Fig. 2, 3:31-34 and 52-57)).
`
`The ’891 patent describes a preferred embodiment in which “virtual output
`
`queues” are not “at” the input ports in the way the Board apparently construed the
`
`term “at.” As such, the Board’s claim interpretation cannot be correct, and, as
`
`Petitioner’s Petition demonstrated, the “virtual output queues” disclosed in
`
`Schwartz are located “at each input port” as claimed given that the broadest
`
`reasonable interpretation of “at” does not require all components of the virtual
`
`output queues be physically located at the input port (indeed, being called
`
`“virtual” suggests that they can be anywhere).
`
`3.
`
`Storing only packets
`
`The Board’s conclusion that Petitioner failed to explain “how the packet
`
`meta-processors, which store meta-data …, teach ‘each virtual output queue …
`
`storing only packets” (Decision at 10) again focuses on the wrong thing – the
`
`8
`
`
`
`meta-data processor – and does not give the claims the broadest reasonable
`
`interpretation.
`
`As explained above (in Section III.B.1) and in the Petition (pages 29-30),
`
`data packets are stored in buffers at the input ports and each data packet has an
`
`associated meta-data packet. The Board offers no explanation why the claimed
`
`“storing data packets” is not the same thing as Schwartz’s storing of data packets
`
`at an input buffer and generating information about those data packets, including a
`
`pointer to each of those data packets, as meta-data packets. The Board also does
`
`not explain why it focuses on Schwartz’s meta-data processor – that processes
`
`meta-data packets (see, e.g., Petition at 30-31; Ex. 1002, Bambos Decl., ¶ 83) – it
`
`does not store meta-data packets.
`
`Additionally, the portion of the claim language cited in the Decision is
`
`incomplete. The claim language does not say that “each virtual output queue …
`
`stor[es] only packets,” it says that “each virtual output queue … stor[es] only
`
`packets destined for the associated output port.” (Decision at 4, 9). Put another
`
`way, the claimed virtual output queues do not store packets destined for output
`
`ports other than the one associated with the virtual output queue. Either way, this
`
`element is disclosed by Schwartz, which states that “each output port module
`
`retrieves meta-data packets from its respective meta-data packet queue.” (Petition
`
`at 29; Ex. 1004 at Abstract (emphasis added)).
`
`9
`
`
`
`4.
`
`Virtual output queues equal to
`the number of output ports
`As to the Board’s conclusion that Petitioner’s quoted portion of Schwartz
`
`fails to show how Schwartz “teaches ‘establishing at each input port, a number of
`
`virtual output queues equal to the number of output ports,’ as claimed” (Decision
`
`at 10-11), the Board misapprehended Schwartz and Petitioner’s argument, and
`
`overlooked the disclosure of the claimed feature in the very passage cited by
`
`Petitioner.
`
`The Board’s Decision appears to find that Petitioner’s statement that
`
`“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’” contradicts the conclusion that Schwartz discloses “establishing at each
`
`input port, a number of virtual output queues equal to the number of output ports.”
`
`(Decision at 9, 10 (citing Petition at 28-31)). But the Board’s Decision overlooks
`
`the portion of Schwartz cited by the Petitioner discloses both systems containing
`
`N and N2 buffers.
`
`Specifically, Petitioner’s discussion of Schwartz in the “Summary of Prior
`
`Art” section of the Petition. (See Petition at 17-21). As Petitioner explained,
`
`“[g]enerally, ‘each output port will effectively provide one queue for each input
`
`port, in which case the total number of queues provided by the switching node
`
`will be on the order of N2, where ‘N’ is the number of input ports, which, in turn
`
`10
`
`
`
`corresponds to the number of output ports.’” (Petition at 18 (citing Ex. 1004, at
`
`2:12-19)). The Board’s Decision appears to have overlooked these relevant
`
`statements in the Petition, thus leading to an incorrect conclusion regarding what
`
`is disclosed in Schwartz. But as is clear from the above portions of Schwartz that
`
`were cited in the Petition, Schwartz does disclose ‘establishing at each input port,
`
`a number of virtual output queues equal to the number of output ports” as part of
`
`the prior art.
`
`According to the plain language of the above passage cited in the Petition,
`
`the invention of Schwartz is a system in which N buffers are sufficient. But
`
`Schwartz also discloses that there were prior art output-queued switching nodes
`
`that require N2 buffers, that is, one for each output port. Thus, far from failing to
`
`disclose “establishing at each input port, a number of virtual output queues equal
`
`to the number of output ports,” Schwartz correctly identifies this element as
`
`already having been well-known in the art.
`
`C.
`
`Summary – Claim Chart
`
`To summarize, an element-by-element chart is presented below:
`
`11
`
`
`
`’891 Claim 1(a)
`Element
`establishing at each
`input port
`
`a number of virtual
`output queues equal
`to the number of
`output ports, each
`virtual output queue
`at each input port
`dedicated to an
`individual output
`port
`
`Location in
`Petition
`
`pp. 19, 29
`
`pp. 18, 30
`
`Schwartz’s Disclosure
`“each input port module, upon receiving
`a packet … buffers the packet and
`generates a meta-data packet therefor”
`(Ex. 1004 at 3:19-23)
`
`Packets are stored at input buffers and
`meta-data packets are generated at the
`input port
`“each output port module retrieves meta-
`data packets from its respective meta-
`data packet queue” (Ex. 1004, Abstract)
`
`“each output port will effectively provide
`one queue for each input port, in which
`case the total number of queues provided
`by the switching node will be on the
`order of N2, where ‘N’ is the number of
`input ports, which, in turn corresponds to
`the number of output ports” (Ex. 1004,
`2:12-19).
`
`Output ports each have their own
`respective meta-data packet queues, thus
`there are the same number of meta-data
`packet queues as output ports; Schwartz
`teaches that this feature has long been
`known in the prior art as well
`
`12
`
`
`
`’891 Claim 1(a)
`Element
`storing only packets
`desired for the
`associated output
`port
`
`Schwartz’s Disclosure
`“the meta-data packet identif[ies] the
`output port module that is to transmit the
`packet, and generates identifier
`information for the packet” (Ex. 1004 at
`3:19-23)
`
`Location in
`Petition
`
`“each output port module retrieves meta-
`data packets from its respective meta-
`data packet queue” (Ex. 1004, Abstract)
`
`p. 29
`
`for managing
`incoming data
`traffic
`
`The meta-data packets include
`identifying information for specific
`target output ports in order to direct
`packet stored at the input buffer to a
`specific output port
`“The invention relates generally to the
`field of digital communications, and more
`particularly to systems and method for
`switching packets of digital data in a
`switching node used in a digital data
`network.” (Ex. 1004 at 1:6-7).
`
`“the packet meta-data processor
`effectively provides for output queuing of
`information used in making the pass/drop
`decision” (Ex. 1004 at 12:24-25)
`
`Managing incoming data traffic, or
`switching packets of digital data in a
`switching node, is the very purpose of
`Schwartz
`
`pp. 26, 30
`
`13
`
`
`
`IV. CONCLUSION
`
`For the foregoing reasons, Petitioner requests that the Board reverse its
`
`Decision with regard to Ground 1 (Schwartz and Muller), and institute Inter
`
`Partes Review of U.S. Patent No. 6,831,891 on that Ground.
`
`Dated: May 30, 2019
`
`
`
`Respectfully Submitted,
`
`/s/ Sasha G. Rao
`Sasha G. Rao
`Reg. No. 57,017
`MAYNARD COOPER & GALE LLP
`Transamerica Pyramid Center
`600 Montgomery St., Suite 2600
`San Francisco, CA 94111
`srao@maynardcooper.com
`Tel: 415.646.4702
`Fax: 415.358.5650
`
`Attorneys for Petitioner
`
`14
`
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. §§ 42.6(e)(4) and 42.105, the undersigned hereby
`
`certifies that on this date, a true and correct copy of the foregoing REQUEST
`
`FOR REHEARING PURSUANT TO 37 C.F.R. § 42.71(d) was served via
`
`Electronic Mail on the Patent Owner at the following correspondence address:
`
`Douglas Bridges
`bridges@capitallegalgroup.com
`
`Greg Donahue
`gdonahue@dinovoprice.com
`
`Dated: May 30, 2019
`
`/s/ Sasha G. Rao
`Sasha G. Rao
`Reg. No. 57,017
`MAYNARD, COOPER & GALE, LLP
`Transamerica Pyramid Center
`600 Montgomery Street, Suite 2600
`San Francisco, CA 94111
`srao@maynardcooper.com
`Telephone: 415.646.4702
`Fax: 415.358.5650
`
`Attorney for Petitioner
`
`15
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
