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.: To Be Assigned
`Patent No.: 6,831,891
`
`DECLARATION OF DR. NICHOLAS BAMBOS
`
`{04508215.1}
`
`

`

`TABLE OF CONTENTS
`
`I.
`
`PROFESSIONAL BACKGROUND ............................................................... 1
`
`II. MATERIALS REVIEWED AND CONSIDERED ........................................ 3
`
`III. MY UNDERSTANDING OF CERTAIN PATENT LAW
`PRINCIPLES ................................................................................................... 5
`
`A.
`
`B.
`
`C.
`
`Anticipation ........................................................................................... 6
`
`Obviousness ........................................................................................... 7
`
`Claim Construction................................................................................ 9
`
`IV.
`
`V.
`
`THE PERSON OF ORDINARY SKILL IN THE ART ............................... 10
`
`SUMMARY OF THE ’891 PATENT ........................................................... 11
`
`B.
`
`C.
`
`Prosecution History of the ’891 Patent ............................................... 17
`
`The ’891 Patent Claims ....................................................................... 18
`
`VI.
`
`SCOPE AND CONTENT OF THE PRIOR ART ......................................... 21
`
`A.
`
`B.
`
`D.
`
`Background ......................................................................................... 21
`
`The Schwartz Patent Publication (Ex. 1004) ..................................... 22
`
`The Muller Patent Publication (Ex. 1005) .......................................... 27
`
`VII. CLAIMS 1-6 ARE UNPATENTABLE IN LIGHT OF THE PRIOR
`ART ............................................................................................................... 30
`
`VIII. COMPARISON OF THE PRIOR ART TO THE ’891 PATENT ................ 30
`
`A.
`
`Ground 1: Schwartz (Ex. 1004) in View of Muller (Ex. 1005)
`Would Have Rendered Claims 1-6 Obvious ....................................... 30
`
`1.
`
`2.
`
`Reasons to Combine Schwartz and Muller .............................. 30
`
`Claim 1 Would Have Been Obvious Over Schwartz in View of
`Muller ........................................................................................ 32
`
`{04508215.1}
`
`ii
`
`

`

`i.
`
`ii.
`
`iii.
`
`iv.
`
`v.
`
`Preamble: “A method for managing data traffic at
`a switching element in a fabric network, the
`switching element having two or more internally
`coupled ports” ................................................................. 32
`
`Limitation 1[A]: “(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” .................................... 34
`
`Limitation 1[B]: “(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” .................................................... 37
`
`Limitation 1[C]: “wherein in step (b), the queue
`manager increases the rate of discarding as
`quantity of queued data increases above the preset
`threshold” ........................................................................ 41
`
`Limitation 1[D]: “discarding all data traffic when
`the queue is full” ............................................................. 46
`
`3.
`
`Claim 2 Would Have Been Obvious Over Schwartz in View of
`Muller ........................................................................................ 46
`
`i.
`
`ii.
`
`iii.
`
`Preamble: “A switching element for a fabric
`network” ......................................................................... 47
`
`Limitation 3[A]: “a plurality of input and output
`ports” ............................................................................... 48
`
`Limitation 3[B]: “a number of virtual output
`queues at each input port equal to the number of
`iii
`
`{04508215.1}
`
`

`

`iv.
`
`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” ..................................................................... 48
`
`Limitation 3[C]: “characterized in that a queue
`manager accepts or discards data directed to a
`queue according to a quantity of data in the queue
`relative to the queue capacity by monitoring
`quantity of queued data against 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” .............. 48
`
`v.
`
`Limitation 3[D]: “wherein all data is discarded for
`a full queue” .................................................................... 48
`
`6.
`
`Claim 5 Would Have Been Obvious Over Schwartz in View of
`Muller ........................................................................................ 49
`
`i.
`
`ii.
`
`iii.
`
`iv.
`
`Preamble: “A data router having external
`connections to other data routers” .................................. 50
`
`Limitation 5[A]: “an internal fabric network” .............. 51
`
`Limitation 5[B]: “a plurality of switching element
`nodes in the internal fabric network, each
`switching element node having a plurality of input
`and output ports, and 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” ..................................................................... 52
`
`Limitation 5[C]: “characterized in that a queue
`manager accepts or discards data directed to a
`queue according to a quantity of data in the queue
`relative to the queue capacity by monitoring the
`quantity of queued data against a preset threshold,
`iv
`
`{04508215.1}
`
`

`

`and begin to discard data from each virtual output
`queue at a predetermined rate, when the quantity
`of queued data reaches or exceeds the threshold” .......... 52
`
`v.
`
`Limitation 5[D]: “wherein the queue manager
`increases the rate of discarding as quantity of
`queued data increases above the preset threshold” ........ 52
`
`B.
`
`Ground 2: Firoiu (Ex. 1006) in view of Muller (Ex. 1005)
`Would Have Rendered Claims 1-6 Obvious ....................................... 53
`
`1.
`
`2.
`
`Reasons to Combine Firoiu and Muller ................................... 53
`
`Claim 1 Would Have Been Obvious Over Firoiu in view of
`Muller ........................................................................................ 55
`
`i.
`
`ii.
`
`iii.
`
`Preamble: “A method for managing data traffic at
`a switching element in a fabric network, the
`switching element having two or more internally
`coupled ports” ................................................................. 55
`
`Limitation 1[A]: “(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” .................................... 56
`
`Limitation 1[B]: “(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” .................................................... 57
`
`iv.
`
`Limitation 1[C]: “wherein in step (b), the queue
`manager increases the rate of discarding as
`
`{04508215.1}
`
`v
`
`

`

`quantity of queued data increases above the preset
`threshold” ........................................................................ 60
`
`v.
`
`Limitation 1[D]: “discarding all data traffic when
`the queue is full” ............................................................. 64
`
`3.
`
`4.
`
`Claim 2 Would Have Been Obvious Over Firoiu in View of
`Muller ........................................................................................ 64
`
`Claim 3 Would Have Been Obvious Over Firoiu in View of
`Muller ........................................................................................ 65
`
`i.
`
`ii.
`
`iii.
`
`iv.
`
`v.
`
`i.
`
`Preamble: “A switching element node for a fabric
`network” ......................................................................... 65
`
`Limitation 3[A]: “a plurality of input an[d] output
`ports” ............................................................................... 66
`
`Limitation 3[B]: “a number of virtual output
`queues at each input port 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” ..................................................................... 66
`
`Limitation 3[C]: “characterized in that a queue
`manager accepts or discards data directed to a
`queue according to a quantity of data in the queue
`relative to the queue capacity by monitoring
`quantity of queued data against 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” .............. 66
`
`Limitation 3[D]: “wherein the queue manager
`increases the rate of discarding as quantity of
`queued data increases above the preset threshold” ........ 66
`
`Preamble: “A data router having external
`connections to other data routers” .................................. 68
`
`{04508215.1}
`
`vi
`
`

`

`ii.
`
`iii.
`
`iv.
`
`Limitation 5[A]: “an internal fabric network” .............. 68
`
`Limitation 5[B]: “a plurality of switching element
`nodes in the internal fabric network, each
`switching element node having a plurality of input
`and output ports, and 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” ..................................................................... 69
`
`Limitation 5[C]: “characterized in that a queue
`manager accepts or discards data directed to a
`queue according to a quantity of data in the queue
`relative to the queue capacity by monitoring the
`quantity of queued data against a preset threshold,
`and begin to discard data from each virtual output
`queue at a predetermined rate, when the quantity
`of queued data reaches or exceeds the threshold” .......... 69
`
`v.
`
`Limitation 5D: “wherein all incoming data is
`discarded for a full queue” .............................................. 70
`
`IX. OBJECTIVE FACTORS OF NONOBVIOUSNESS ................................... 70
`
`X.
`
`STATEMENT UNDER 18 U.S.C. § 1001 .................................................... 71
`
`{04508215.1}
`
`vii
`
`

`

`I, Dr. Nicholas Bambos, declare:
`
`1.
`
`I have been retained by Maynard, Cooper & Gale, counsel for
`
`Petitioner Juniper Networks, Inc. (“Petitioner”), to analyze Claims 1-6 (“the
`
`Challenged Claims”) of U.S. Patent No. 6,831,891 (“the ’891 Patent”) in light of
`
`various prior art references and my knowledge and experience in connection with a
`
`Petition for Inter Partes Review of Claims 1-6 of the ’891 Patent. I am being
`
`compensated for my time working on this matter at my regular rate of $450 per
`
`hour, plus my actual expenses. My compensation is not dependent in any way
`
`upon the outcome of the Petition. I hold no financial interest in the Petitioner or
`
`the Patent Owner.
`
`I.
`
`PROFESSIONAL BACKGROUND
`
`2.
`
`I am R. Weiland Professor of Engineering at Stanford University,
`
`having a joint appointment in the Department of Electrical Engineering and the
`
`Department of Management Science & Engineering. I am also currently serving as
`
`the Fortinet Chairman of the Department of Management Science & Engineering.
`
`3.
`
`Before joining Stanford as an Associate Professor in 1996, I was since
`
`1989 an Assistant Professor and then tenured Associate Professor in the Electrical
`
`Engineering department of University of California at Los Angeles (UCLA).
`
`4.
`
`I received my Ph.D. from the University of California at Berkeley
`
`(1989) in Electrical Engineering and Computer Sciences (EECS). Also from U.C.
`
`{04508215.1}
`
`1
`
`

`

`Berkeley, I received a M.S. in EECS (1987) and a M.A. in Mathematics (1989). I
`
`graduated in Electrical Engineering from the National Technical University of
`
`Athens-Greece (1984) with first class honors. While at U.C. Berkeley, I had been
`
`a U.C. Regents Fellow, a David Gale Fellow, an Earl Anthony Fellow, and EECS
`
`Departmental Scholar.
`
`5.
`
`At Stanford University, I head the Network Architecture and
`
`Performance Engineering research group, working on high-performance design of
`
`computer systems and networks. I have researched various high performance
`
`design aspects of wireline/wireless networking and computing and have published
`
`numerous papers on such topics.
`
`6.
`
`From 1999 to 2005, I was the Director of the Stanford Networking
`
`Research Center project. I have held the Cisco Systems Faculty Development
`
`Chair (1999-2003) in computer networking at Stanford University and have won
`
`the IBM Faculty Development Award (2002) for research in performance
`
`engineering of computer systems and networks.
`
`7.
`
`I have also been the recipient of the National Young Investigator
`
`Award of the National Science Foundation (1992). I have served as editor of
`
`various research journals (including the “Computer Networks” and “Wireless
`
`Networks” research journals), as technical reviewer for numerous networking and
`
`{04508215.1}
`
`2
`
`

`

`computing research journals, and on various technical panels for the National
`
`Science Foundation.
`
`8.
`
`For over 25 years, I have done research in and taught
`
`computing/networking technology concepts and design principles (at Stanford
`
`since 1996 and at UCLA during 1989-96). I have graduated over 25 Ph.D.
`
`students who have then been in leadership positions in academia and the
`
`information technology industry (e.g., Stanford University, California Institute of
`
`Technology, Columbia University, New York University, University of Michigan;
`
`Cisco, IBM Labs, Qualcomm, ST Micro, Google, Intel, Nokia, MITRE, Sun Labs,
`
`Facebook, Twitter, etc.).
`
`9.
`
`I am an expert in system architecture and high-performance
`
`engineering of computer networks/systems and have published over 200 peer-
`
`reviewed research papers in this field (including numerous on packet switches in
`
`particular), and have given numerous technical talks in this field world-wide. I am
`
`a named inventor on eight patents, and have served as a technical expert witness in
`
`numerous patent litigation cases. My full qualifications and experience are set
`
`forth in my Curriculum Vitae, which is attached as Exhibit 1003 to this declaration.
`
`II. MATERIALS REVIEWED AND CONSIDERED
`
`10. My findings contained in this declaration are based on my education,
`
`research, experience, and background in the field of wireless/wireline networking
`
`{04508215.1}
`
`3
`
`

`

`and computing, as well as my review of prior art references and other documents
`
`disclosed in this declaration. In forming my opinions, I have studied and
`
`considered the documents discussed herein and identified below:
`
`• U.S. Patent No. 6,831,891 to Mansharamani (“the ’891 Patent”) (Ex.
`
`1001)
`
`• PCT International Application No. WO 00/02347 A2 to Schwartz et al.
`
`(“Schwartz ”) (Ex. 1004)
`
`• PCT International Application No. WO 00/52882 A2 to Muller et al.
`
`(“Muller”) (Ex. 1005)
`
`• Canadian Patent Application No. CA 2 310 531 A1 to Firoiu et al.
`
`(“Firoiu”) (Ex. 1006)
`
`• Defendants Hewlett Packard Enterprise Company, Ericsson Inc., and
`
`Juniper Networks, Inc.’s Initial Invalidity Contentions in Parity
`
`Networks, LLC v. Hewlett Packard Enterprise Company, et al., 6:17-CV-
`
`00683 (E.D. Tex.) (May 17, 2018), and Exhibits I-1 to I-3 thereto.
`
`11.
`
`I understand that this declaration will be submitted in support of a
`
`Petition requesting inter partes review of the ’891 Patent.
`
`{04508215.1}
`
`4
`
`

`

`III. MY UNDERSTANDING OF CERTAIN PATENT LAW PRINCIPLES
`
`12.
`
`I have been informed by counsel about some legal principles related
`
`to patent law and have relied upon those legal principles in forming my opinions
`
`set forth in this declaration.
`
`13.
`
`I am informed by counsel that “inter partes review” is a proceeding
`
`before the United States Patent & Trademark Office (“Patent Office”) for
`
`evaluating the patentability of an issued patent claim based on prior art patents and
`
`printed publications. I am informed by counsel that, during an inter partes review,
`
`claims in a patent are given their broadest reasonable interpretation (“BRI”) in
`
`light of the patent specification.
`
`14.
`
`In connection with this matter, I am informed by counsel that
`
`Petitioner has the burden of proving that the claims of the ’891 Patent are
`
`unpatentable by a preponderance of the evidence. I am informed by counsel that
`
`“preponderance of the evidence” means that a fact or conclusion is more likely true
`
`than not true.
`
`15.
`
`I am informed by counsel that for an invention claimed in a patent to
`
`be patentable, it must be, among other things, new (novel) and not obvious from
`
`the prior art to a person of ordinary skill in the art (“POSA”) at the time the
`
`invention allegedly was made. I am informed by counsel that the information used
`
`to evaluate whether a claimed invention is patentable is generally referred to as
`
`{04508215.1}
`
`5
`
`

`

`“prior art,” and includes patents and printed publications (e.g., books, journal
`
`publications, articles on websites, product manuals, etc.).
`
`16.
`
`I am informed by counsel that there are two ways of proving
`
`invalidity of a patent claim in view of prior art. First, I understand that prior art
`
`may “anticipate” the claim. Second, I understand the prior art may have made the
`
`claim “obvious” to a POSA at the time the invention was made. My understanding
`
`of these two legal standards is set forth below.
`
`A. Anticipation
`
`17.
`
`I am informed by counsel that, for a patent claim to be “anticipated”
`
`by the prior art, each and every limitation of the claim must be found, expressly,
`
`implicitly, or inherently, in a single prior art reference.
`
`18.
`
`I am informed by counsel that in order for a claim limitation to be
`
`implicit in a prior art reference, the disclosure must be based on inferences that a
`
`person of ordinary skill would reasonably be expected to draw from the express
`
`teachings in the reference when read in light of a POSA’s knowledge and
`
`experience.
`
`19.
`
`I am informed by counsel that a claim limitation is inherent in a prior
`
`art reference if that limitation is necessarily present when teachings of the
`
`reference are practiced, regardless of whether a POSA recognized the presence of
`
`that limitation in the prior art.
`
`{04508215.1}
`
`6
`
`

`

`B. Obviousness
`
`20.
`
`I am informed by counsel that the following standards govern the
`
`determination of whether a patent claim would have been “obvious” in view of the
`
`prior art at the time the subject matter of the patent claim was said to have been
`
`invented.
`
`21.
`
`I am informed by counsel that a patent claim may be unpatentable if it
`
`would have been obvious in view of a single prior art reference or a combination of
`
`prior art references.
`
`22.
`
`I am informed by counsel that a patent claim would have been
`
`obvious if the differences between the subject matter of the claim and the prior art
`
`are such that the subject matter as a whole would have been obvious to a POSA at
`
`the time the alleged invention was made. Specifically, I am informed that the
`
`obviousness question involves a consideration of:
`
`•
`
`•
`
`•
`
`•
`
`the scope and content of the prior art;
`
`the differences between the prior art and the claims at issue;
`
`the knowledge of a person of ordinary skill in the art in the pertinent
`
`art; and
`
`whatever objective factors indicating obviousness or non-obviousness
`
`may be present in any particular case – what I am told by counsel are
`
`referred to as “secondary considerations.”
`
`{04508215.1}
`
`7
`
`

`

`23.
`
`I am informed by counsel that in order for a claimed invention to be
`
`considered obvious, a POSA must have had a reason for combining teachings from
`
`multiple prior art references (or for altering a single prior art reference, in the case
`
`of single-reference obviousness) in the fashion proposed.
`
`24.
`
`I am further informed by counsel that in determining whether a prior
`
`art reference would have been combined with other prior art or with other
`
`information within the knowledge of a POSA, the following are examples of
`
`approaches and rationales that may be considered:
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`combining prior art elements according to known methods to yield
`
`predictable results;
`
`simple substitution of one known element for another to obtain
`
`predictable results;
`
`use of a known technique to improve similar devices in the same way;
`
`applying a known technique to a known device ready for
`
`improvement to yield predictable results;
`
`applying a technique or approach that would have been “obvious to
`
`try,” i.e., choosing from a finite number of identified, predictable
`
`solutions, with a reasonable expectation of success;
`
`known work in one field of endeavor may prompt variations of it for
`
`use in either the same field or a different one based on design
`
`{04508215.1}
`
`8
`
`

`

`•
`
`•
`
`incentives or other market forces if the variations would have been
`
`predictable to one of ordinary skill in the art;
`
`numerical ranges disclosed in the prior art that overlap with numerical
`
`limitations set forth in the challenged claims;
`
`whether certain aspects of the patented subject matter were result-
`
`effective, such that a person of ordinary skill in the art would know
`
`that such element is determinative as to the effectiveness of the patent
`
`subject matter; and
`
`•
`
`some teaching, suggestion, or motivation in the prior art that would
`
`have led one of ordinary skill to modify the prior art reference or to
`
`combine prior art reference teachings to arrive at the claimed
`
`invention. I understand that this teaching, suggestion or motivation
`
`may come from prior art reference or from the knowledge or common
`
`sense of one of ordinary skill in the art.
`
`C. Claim Construction
`
`25.
`
`I am informed by counsel that the terms of the claims must first be
`
`construed before they can be properly compared to the prior art references. I am
`
`informed that in the Patent Office, the proper construction of the claims is typically
`
`the broadest reasonable interpretation (“BRI”) in light of the specification.
`
`{04508215.1}
`
`9
`
`

`

`26.
`
`I am also informed by counsel that there is a possibility that the Board
`
`could apply the standard used by United States District Courts for claim
`
`interpretation in this proceeding.
`
`27.
`
`I am further informed by counsel that, in District Courts, terms in
`
`patent claims are interpreted based on the meanings that those patent terms would
`
`have to a person of ordinary skill in the art in question at the time of the alleged
`
`invention – that is, as of the effective filing date of the patent application. I am
`
`informed by counsel that this is a narrower interpretation of the claims than BRI.
`
`28.
`
`In this Petition, my opinions regarding the invalidity of the ’891
`
`Patent stand regardless of whether the ’891 Patent claims are construed using the
`
`BRI standard or the District Court standard. Where the ’891 Patent explicitly
`
`defines a claim term, I apply that meaning in my analysis.
`
`IV. THE PERSON OF ORDINARY SKILL IN THE ART
`
`29.
`
`In evaluating the prior art references, I have used the perspective of a
`
`person of ordinary skill in the art (“POSA”) to which the patent is related as of the
`
`time of the patent’s priority date. I understand that a POSA is presumed to be
`
`aware of all pertinent prior art and the conventional wisdom in the art, and is a
`
`person of ordinary creativity.
`
`30.
`
`I have applied this standard throughout my declaration.
`
`{04508215.1}
`
`10
`
`

`

`31.
`
`The ’891 Patent is entitled “System for Fabric Packet Control” and is
`
`directed to the field of routing packets through alternative paths between nodes in a
`
`routing fabric, or “flow control”, and pertains in particular to methods by which
`
`back-ups in a fabric may be avoided. Ex. 1001 at col. 1, ll. 5-9. A POSA in the
`
`March 6, 2001 timeframe, which is the earliest claimed effective filing date of the
`
`’891 patent, would have had at least a bachelor’s degree in computer science,
`
`computer engineering, electrical engineering, or a related field, and either (a) a
`
`master’s degree in computer science, computer engineering, electrical engineering,
`
`or a related field or (b) two or more years of work or research experience in
`
`networking and computing.
`
`32. My opinions regarding the level of ordinary skill in the art are
`
`informed by, among other things, my experience in the field of the ’891 Patent and
`
`in networking and computing (as described above), my understanding of the basic
`
`qualifications that would be relevant to an engineer or scientist tasked with
`
`investigating methods and systems in the relevant field, and my familiarity with the
`
`backgrounds of my engineers.
`
`V.
`
`SUMMARY OF THE ’891 PATENT
`
`33.
`
`I am informed by counsel that the earliest effective filing date of the
`
`’891 Patent is March 6, 2001. The ’891 Patent is entitled “System for Fabric
`
`Packet Control” and is directed to the field of routing packets through alternative
`
`{04508215.1}
`
`11
`
`

`

`paths between nodes in a routing fabric, and pertains in particular to methods by
`
`which back-ups in a fabric may be avoided. Ex. 1001 at col. 1, ll. 5-9.
`
`34.
`
`The ’891 Patent purports to disclose “a method for managing data
`
`traffic in nodes in a fabric network, each node having internally-coupled ports,
`
`follows the steps of establishing a managed queuing system comprising one or
`
`more queues associated with each port, for managing incoming data traffic, and
`
`accepting or discarding data directed to a queue according to the quantity of data in
`
`the queue relative to queue capacity. Id. at Abstract. No structural elements
`
`encompassing the queue manager are disclosed in the specification.
`
`35.
`
`Figure 1 of the ’891 Patent (reproduced above), “labeled prior art,
`
`illustrates a number of interconnected fabric nodes, labeled in this example A
`
`{04508215.1}
`
`12
`
`

`

`through J, each node of which may be fairly considered to comprise a fabric card
`
`in a switching fabric in a router.” Id. at col. 1, ll. 26-29. Figure 1 “illustrate[s] that
`
`there are a wide variety of alternative paths that data may take within a switching
`
`fabric. For example, transmission from node E to node J may proceed either via
`
`path E-F-H-G-J, or alternatively via E-F-D-G-J.” Id. at col. 1, ll. 34-38.
`
`36.
`
`The ’891 Patent explains that in conventional switching fabric “at the
`
`time of the present patent application fabric nodes in such a structure are
`
`implemented on fabric cards or chips that do Flow Control. Such Flow Control is
`
`very well-known in the art, and comprises a process of monitoring ports for real or
`
`potential traffic overflow, and notifying an upstream port to stop or slow sending
`
`of further data. That is, if node G as shown in FIG. 1, becomes overloaded at a
`
`particular input port, for example, the port from D, the Flow Control at G will
`
`notify D to restrict or suspend traffic to G[.] In this example, D may receive traffic
`
`from upstream neighbors that it cannot forward to G, and it may then have to
`
`notify these neighbors to suspend sending traffic to D.” Id. at col. 1, ll. 43-55.
`
`37. A “serious problem with Flow Control as conventionally practiced is
`
`that the upstream notifications, inherent in flow control, propagate further
`
`upstream and hinder or stop traffic that there is no need to stop, partly because the
`
`interconnections of nodes may be quite complicated and the alternative paths quite
`
`numerous. Further, a node that has been informed of a downstream overload
`
`{04508215.1}
`
`13
`
`

`

`condition cannot select to stop or divert traffic just for that particular link, but only
`
`to stop or divert all traffic. These effects, because of the complexity and
`
`interconnection of nodes in a fabric, can result in complete stultification of parts of
`
`a system, or of an entire network.” Id. at col. 1, l. 64 to col. 2, ll. 8.
`
`38.
`
`The patent states that “[w]hat is clearly needed is a way to deal with
`
`temporary overloads at fabric nodes without resorting to problematic upstream
`
`messaging without impacting traffic that does not use the overloaded link.” Id. at
`
`col. 2, ll.14-17.
`
`39.
`
`The ’891 Patent explains that “a preferred embodiment of the present
`
`invention a method for managing data traffic at switching element in a fabric
`
`network, each node having two or more internally coupled ports is provided,
`
`comprising the steps of (a) establishing a managed queuing system comprising one
`
`or more queues associated with each port, for managing incoming data traffic; and
`
`(b) accepting or discarding data directed to a queue according to the quantity of
`
`data in the queue relative to queue capacity.” Id. at col. 2, ll. 20-29.
`
`40.
`
`“In some embodiments all data is discarded for a full queue. In some
`
`other embodiments the queue manager monitors quantity of queued data in relation
`
`to a preset threshold, and begins to discard data at a predetermined rate when the
`
`quantity of queued data reaches the threshold. In still other embodiments the
`
`queue manager increases the rate of discarding as quantity of queued data increases
`
`{04508215.1}
`
`14
`
`

`

`above the preset threshold, discarding all data traffic when the queue is full.” Id. at
`
`col. 2, ll. 30-38.
`
`41.
`
`Figure 2 is a plan view of a fabric card 201 that has “nine queue
`
`managers 209, one for each external port 205, with each queue manager isolated
`
`from its connected external port by an optical interface 207. The inter-node
`
`communication in this embodiment is by optical links. Queue managers 209
`
`interface with crossbar 203, which connects each of the nine ports with the other
`
`eight ports internally in this embodiment, although these internal connections are
`
`not shown”. Id. at col. 3, ll. 32-39.
`
`{04508215.1}
`
`15
`
`

`

`42.
`
`Each port on each card “passes through a queue management gate
`
`209.” Id. at col. 3, ll. 52-53. Each “queue manager comprises a set of virtual
`
`output queues (VOQ), with individual VOQs associated with individual ones of the
`
`available outputs on a card. This VOQ queuing system manages incoming flows
`
`based on the outputs to which incoming packets are directed. Data traffic coming
`
`in on any one port, for example, is directed to a first-in-first-out (FIFO) queue
`
`associated with an output port, and the queue manager is enabled to discard all
`
`traffic when the queue to which data is directed is full.” Id. at col. 3, ll. 54-62.
`
`43.
`
`The size of each queue “is set to provide adequate flow under
`
`ordinary, and to some extent extraordinary, load conditions without data loss, but
`
`under extreme conditions, when a queue is full, data is simply discarded until the
`
`situation corrects, which the inventors have found to be less conducive to data loss
`
`than the problems associated with conventional Flow Control, which uses the
`
`previously described upstream-propagated Flow Control indicators.” Id. at col. 3,
`
`l. 66 to col. 4, l. 7.
`
`44.
`
` In an alternative embodiment, “each queue manager on a card has an
`
`ability to begin to drop packets at a pre-determined rate at s