trials@uspto.gov
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`IPR2016-00303, Paper No. 51
`IPR2016-00306, Paper No. 34
`IPR2016-00308, Paper No. 40
`IPR2016-00309, Paper No. 49
`April 5, 2017
`
`CONTAINS CONFIDENTIAL INFORMATION
`RECORD OF ORAL HEARING
`UNITED STATES PATENT AND TRADEMARK OFFICE
`- - - - - -
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`- - - - - -
`ARISTA NETWORKS, INC.,
`Petitioner,
`vs.
`CISCO SYSTEMS, INC.,
`Patent Owner.
`- - - - - -
`Case IPR2016-00303 (Patent 6,377,577 B1)
`Case IPR2016-00306 (Patent 7,023,853 B1)
`Case IPR2016-00308 (Patent 7,162,537 B1)
`Case IPR2016-00309 (Patent 7,224,668 B1)
`- - - - - -
` Oral Hearing Held: March 7, 2017
` Before: BRYAN F. MOORE, MIRIAM L. QUINN, MATTHEW R.
`CLEMENTS, and PETER P. CHEN, Administrative Patent Judges
` The above-entitled matter came on for hearing on Tuesday, March 7,
`2017 at the U.S. Patent and Trademark Office, 600 Dulany Street,
`Alexandria, Virginia in Courtroom A, at 1:00 p.m.
`
`
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`IPR2016-00303, Paper No. 51
`IPR2016-00306, Paper No. 34
`IPR2016-00308, Paper No. 40
`IPR2016-00309, Paper No. 49
`April 5, 2017
`
`CONTAINS CONFIDENTIAL INFORMATION
`RECORD OF ORAL HEARING
`UNITED STATES PATENT AND TRADEMARK OFFICE
`- - - - - -
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`- - - - - -
`ARISTA NETWORKS, INC.,
`Petitioner,
`vs.
`CISCO SYSTEMS, INC.,
`Patent Owner.
`- - - - - -
`Case IPR2016-00303 (Patent 6,377,577 B1)
`Case IPR2016-00306 (Patent 7,023,853 B1)
`Case IPR2016-00308 (Patent 7,162,537 B1)
`Case IPR2016-00309 (Patent 7,224,668 B1)
`- - - - - -
` Oral Hearing Held: March 7, 2017
` Before: BRYAN F. MOORE, MIRIAM L. QUINN, MATTHEW R.
`CLEMENTS, and PETER P. CHEN, Administrative Patent Judges
` The above-entitled matter came on for hearing on Tuesday, March 7,
`2017 at the U.S. Patent and Trademark Office, 600 Dulany Street,
`Alexandria, Virginia in Courtroom A, at 1:00 p.m.
`
`
`
`trials@uspto.gov
`
`
`
`571-272-7822
`
`
`APPEARANCES:
`
`
`
`
`
`
`
`
`IPR2016-00303, Paper No. 51
`IPR2016-00306, Paper No. 34
`IPR2016-00308, Paper No. 40
`IPR2016-00309, Paper No. 49
`April 5, 2017
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`W. KARL RENNER, ESQ.
`LAUREN A. DEGNAN, ESQ.
`FISH & RICHARDSON, PC
`1425 K Street, NW
`Eleventh Floor
`Washington, DC 20005
` (202) 626-6447
`
`
`MATTHEW D. POWERS, ESQ.
`TENSEGRITY LAW GROUP LLP
`55 Twin Dolphin Drive
`Suite 650
`
`Redwood Shores, CA 94065
`
` (650) 802-6010
`
`2
`
`
`
`trials@uspto.gov
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`IPR2016-00303, Paper No. 51
`IPR2016-00306, Paper No. 34
`IPR2016-00308, Paper No. 40
`IPR2016-00309, Paper No. 49
`April 5, 2017
`
`APPEARANCES: (Cont’d)
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`LORI A. GORDON, ESQ.
`
`JON E. WRIGHT, ESQ.
`
`DANIEL BLOCK, ESQ.
`
`STERNE, KESSLER, GOLDSTEIN, FOX
`
`1100 New York Avenue, NW
`
`Washington, DC 20005
`
`(202) 371-2600
`
`
`
`3
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`
`P R O C E E D I N G S
`
`(1:00 p.m.)
`JUDGE MOORE: Good morning. This is the oral
`hearing in IPRs 2016-00303, 306, 308, and 309. With us this
`morning, to my right, Judge Quinn, and to my left, Judges
`Chen and Clements.
`As I'm pointing out the remote judges, I will take
`this time to say that if you are using evidence today, in going
`through your slides, remember that the judges are remote and
`remember to refer to the page on the slide and remember to
`refer specifically to the part of evidence if it's not a
`demonstrative slide so that they can follow the presentation.
`With that, we should do a roll call. We'll start
`with Patent Owner.
`MS. GORDON: Thank you, your Honor. Lori
`Gordon from the law firm of Sterne, Kessler, Goldstein &
`Fox. With me today is Jon Wright from Sterne Kessler and
`Dan Block, and we are joined by Buddy Tolliver from Cisco
`Systems.
`
`JUDGE MOORE: And for Petitioner.
`MR. RENNER: Yes, your Honor. Using the
`microphone. Make it a little easier. And we have some
`
`
`
`4
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`copies of our slides to approach with, if it's your Honor's
`pleasure.
`
`JUDGE MOORE: Sure. If you want to --
`MR. RENNER: This is Karl -- I'm Karl Renner
`from Fish & Richardson, and I'm joined by Matt Powers, as
`well as Will Nelson and Lauren Degnan, Sean Sproul, Linhong
`Zhang, and we also have from Arista Sean Christofferson and
`also Nick Atchison.
`JUDGE MOORE: Thank you.
`And I'll make a point here of saying that we are
`going to -- as the parties spoke to the Board on the phone
`yesterday, we're going to separate the issues in this trial, and
`there are certain issues that may raise confidential
`information. Those issues will be held to the end of the trial,
`and I'm going to need the parties to estimate to me what time
`they need to reserve to handle those matters.
`The other thing is that if, for some reason, the
`other side gets into some confidential information, or you
`believe that they are, certainly immediately alert me of that;
`otherwise, please hold all objections until the other side's
`presentation is over. For example, objections as to things
`being beyond the scope of what should not be presented
`
`
`
`5
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`during trial, those should be held until -- until your
`presentation and not interrupt the other side's presentation.
`We have set in the trial order 90 minutes for all
`cases, and we have left it to the parties to determine how to
`allocate that time. Petitioner has the burden of proof, so
`Petitioner will go first.
`Petitioner, as we have mentioned, if you could let
`us know before you get started about how much time you are
`going to reserve for your rebuttal and then also for the final
`presentation.
`MR. POWERS: Thank you, your Honor. For
`timing, we would propose to do 55 minutes of our 90 for the
`initial presentation, and then 30 minutes for rebuttal, saving
`approximately five for the confidential issues Your Honor
`referenced.
`
`All right. May I proceed, your Honor?
`JUDGE MOORE: Certainly.
`MR. POWERS: And the parties have also agreed
`on the sequence of the patents in which we will present. We
`will start with the '668 patent, followed by '577, followed by
`'853, followed by '537.
`JUDGE MOORE: Okay. And could you give me
`
`
`
`6
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`that order in IPR number order. That's helpful.
`MR. POWERS: Sure. So, the IPR number would
`be 309 first, then 303, then 306, and then 308.
`JUDGE MOORE: All right. Thank you.
`MR. POWERS: May I proceed?
`JUDGE MOORE: Certainly.
`MR. POWERS: May it please the Court, we will
`begin, as I said, with the '668 patent, which is the 309
`proceeding. We've shown on slide 2 just a table of contents
`for Your Honors' reference of the slides, which I don't
`propose to discuss in any more detail.
`I'd like to give just a very brief overview of the
`'668 patent before diving directly into the issues that are
`disputed between the parties.
`The '668 patent, as we're showing on slide 5, is
`focused on providing two different paths for data packets, also
`called transit packets, and control plane packets, also called
`internal packets, the internal reflected in red. And those come
`in a physical port and ultimately go to the control plane. And
`the data packets come in the physical port and ultimately go
`out a physical port to be forwarded to another device.
`That basic structure is reflected in Amara -- and
`
`
`
`7
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`this is now slide 6 -- where Amara also has a blue path for the
`transit packets that is different from the path prescribed for
`packets that are destined for the control plane. And that is
`relevant, obviously, to the claim limitation about the -- the
`control plane packets being treated independently of the
`transit packets.
`There are three separate grounds to address. The
`first, of course, is Amara plus CoreBuilder, for a variety of
`claims that are listed on slide 8. The claims that are
`challenged by Cisco are only 1, 19 and 55. And, so, we've
`listed on slide 8 the claims that are not separately challenged
`or contested by Cisco on different grounds from those
`contested in the three claims shown as a reference for your
`Honors.
`
`On slide 9, we've shown in a somewhat busy slide
`the -- the extent of the issues in those independent claims that
`are not disputed. Again, I won't go through this in detail but
`it's for your reference. So, there's very minor issues that are
`actually disputed, and this is a reference for you for that
`point.
`
`Now to the main arguments of the case. The first
`argument that Cisco advances and its primary argument is that
`
`
`
`8
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`the independent claims require that both port services and,
`quote, "control plane port services" be applied to packets that
`are just for the control plane. So, that raises both the claim
`construction issue and a question of what -- of the extent of
`Amara's disclosure.
`As to the claim construction question, Cisco's
`argument fails as a matter of basic construction of the words
`of the claim in the first instance. The word of the claim on
`which Cisco hangs its hat is the word "thereto," and it seeks
`to have that word applied to a word "packets" that's 29 words
`before the word "thereto," rather than the phrase immediately
`before it, which is "physical port interfaces." And normal
`precepts of English grammar and writing would say otherwise.
`So, at a basic level, Cisco's argument fails from
`just reading the claims in a normal way in which those skilled
`in the art would read the claims.
`Cisco's claim construction argument also fails,
`though, as a matter of construction using the broadest
`reasonable interpretation based on the specification. Cisco
`argues in its Patent Owner's response at 19 that the only
`embodiments in the '668, and that's their wording, "only
`embodiments" -- that their only embodiments apply port
`
`
`
`9
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`services to control plane packets, and the specification is
`inconsistent with that statement.
`First, in the '668 patent at column 3, and we're
`now at slide 12, the word that the patent uses to describe
`application of port services is not "always," not
`"consistently," not "necessarily," but "typically." "Typically,"
`by definition, means not always. And the choice of the word
`"typically" is inconsistent with Cisco's position that port
`service must necessarily be applied -- normal port services
`must necessarily be applied to packets destined for the control
`plane.
`
`So, the specification is inconsistent with Cisco's
`position right off the bat. But Cisco's position that the only
`embodiments shown do apply such port services to control
`plane packets is also inconsistent with another embodiment of
`the invention, which is at the '668 patent at column 2, line 63
`to 66. And now we're at slide 13, which has the quotation
`from it. And there's a specific reference to an embodiment
`where an interface, which previously had no configuration,
`would be forced to execute control plane packets for every
`packet it receives.
`Now, an interface or port which had no
`
`
`
`10
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`configuration means there's no port policies being applied,
`yet, still control plane packets would be coming through that
`port. That is explicitly in the '668 disclosure and, therefore,
`dramatically inconsistent with Cisco's assertion regarding the
`extent of the embodiments and the extent of the arguments as
`why the specification supports their construction requiring
`port services to be applied to all control plane packets.
`Of course, some port services can be applied to
`some control plane packets. That's, of course, true, but it is
`not true that it's necessarily true. And that's what the
`specification teaches us.
`JUDGE MOORE: Can you speak to the support in
`the specification for your reading? You are speaking now of
`parts of the specification that contradict their reading of the
`claim, but can you speak to support in the specification for
`your reading of the claim.
`MR. POWERS: The two portions I've just quoted
`support our reading because the word "typically" means it
`does not have to all the time.
`JUDGE MOORE: Right.
`MR. POWERS: Because our position is merely
`that it is not necessarily true that all control plane packets
`
`
`
`11
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`must always be treated with normal port services. And the
`two portions I've just cited to you and quoted support that,
`both in the use of "typically," but also in the use of an
`embodiment where there's no prior configuration, which
`means there's no policy specified for that port.
`But, there's also, I believe, your Honor, in
`response to your question at column 6 of the '668 patent at
`line 39, there's a statement there that also supports our
`position and is inconsistent with Cisco's. And the quotation is
`"Since control plane destined packets will invoke only control
`plane services, transit traffic and system performance is
`minimally impacted."
`So, Cisco's position is all control plane packets
`get normal port services in addition to control plane services.
`This portion of the specification at column 6 says control
`plane packets will invoke only control plane services, not
`normal port services. And, therefore, that portion is also
`inconsistent with Cisco's position and supports ours, as well.
`So, then -- does that answer your question, your
`
`Honor?
`
`JUDGE MOORE: Sure.
`MR. POWERS: Thank you.
`
`
`
`12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`
`And that was at slide 71 of our presentation.
`Rather, the slide 13 was the portion of an interface which
`previously had no configuration.
`But the next point, of course, is even -- so,
`Cisco is wrong as a matter of claim construction.
`But even if Cisco's construction were adopted, i.e., even if it
`were required that port services be applied to packets destined
`to the control plane, Amara discloses that. And at our slide
`71, we show on the left the disclosure from Amara which says
`that packet classifiers, which is a port service, are applied to
`those input ports. And it's applied to those input ports for
`packets that are ultimately destined to go to the control plane,
`as the flow chart of Amara shows quite clearly.
`So, faced with that disclosure, Cisco's response is
`that packet classifiers are not port services. And they base
`their argument, as we show on slide 71, principally on an
`argument that independent - - that dependent claim 17 calls
`packet classification a control plane port service.
`And as a first instance, they're wrong in reading
`the claim. The claim does not say that those are only control
`plane port services. It calls them "services," generically,
`services which are applied to the control plane port, in the
`
`
`
`13
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`instance of claim 17. But it does not say, as Cisco asks you to
`read it, that those class -- those examples of services are
`necessarily only control plane port services. That's not what
`claim 17 says.
`And that's also not what the '668 patent says. If
`you look at the bottom of column 5 and the top of column 6,
`the bottom of the '668 patent says as follows: "With
`processes 155 in the control plane 150 being treated in this
`way, the control plane port 140 can be treated as a traditional
`hardware port." And the more important part is coming right
`up now.
`
`“As a result, a full range of traditional port
`control features," "traditional," that means normal port
`features, "can be applied to help protect the control plane
`from a DoS denial of service attack or to provide other QoS,
`quality of service. Such control features can, for example, be
`implemented as a set of programmed rules that determine
`whether or not packets arriving at the control plane port
`qualify for delivery to the control plane and at what level of
`QoS."
`
`Now, that's describing packet classification, is it a
`control plane packet or not, and it is saying those are
`
`
`
`14
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`examples of traditional port services which can be applied at
`the control plane, exactly what claim 17 is saying. It doesn't
`say those are only control plane port services; it says those
`are traditional port services which can be applied to packets
`destined for the control plane or at the control plane port.
`So, the '668 patent is squarely inconsistent with
`Cisco's argument trying to interpret claim 17 and trying to
`denigrate packet classification services as being only control
`plane port services, not normal port services.
`And those normal port services in packet
`classification in Amara are squarely shown being applied at
`that physical port to the packets coming through that physical
`port and to packets which are destined ultimately for the
`control plane, exactly what Cisco says the claim requires.
`So, even if Cisco's claim construction is adopted,
`Amara discloses that limitation and their claim construction is
`wrong.
`
`Cisco's second argument is that because
`CoreBuilder does not disclose logging packets -- and we're not
`agreeing with the premise of the argument. We want to lay
`out the argument fairly -- the combination of Amara and
`CoreBuilder does not teach the limitation of controlling and
`
`
`
`15
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`monitoring packet flows. That's the argument Cisco makes.
`So, let's look at what the disclosure is. It is
`undisputed that Amara -- and now we're at slide 15. It is
`undisputed that Amara shows that routers and remote service
`processors may perform packet filtering in which certain
`packets are dropped, diverted, and/or logged. That's Amara at
`column 1, lines 31 to 38. So, Amara discloses filtering which
`includes logging.
`So, there's no debate between the parties that
`logging would be -- would satisfy this claim limitation, and
`there's no dispute that Amara discloses logging, and logging
`specifically as part of filtering.
`The other disclosure of logging, of course, in
`Amara is at column 5, lines 16 to 21, which is also on slide
`15.
`
`So, there's no dispute that Amara is showing
`logging and that that satisfies the limitation.
`There's also no dispute that CoreBuilder teaches
`the limitation of define and control plane configurations.
`That's not disputed, as well. We've got that shown on slide
`16, which is CoreBuilder at page 32. And, also, there's no
`dispute, secondly, as to CoreBuilder that CoreBuilder teaches
`
`
`
`16
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`packet filtering. And that's CoreBuilder at 210, which is at
`slide 17.
`
`And, so, the filtering, which you recall in Amara
`included logging, is disclosed as one of the features or
`policies that CoreBuilder would control using control plane
`configurations.
`So, what's Cisco's argument? Cisco's argument is,
`well, CoreBuilder, when it discloses filtering, doesn't say
`itself that filtering includes logging. And that argument has
`two problems. One, CoreBuilder certainly does not say that
`filtering excludes logging. And Amara says filtering includes
`logging.
`
`But perhaps even more fundamentally, Cisco's
`argument fails because when the control plane configurations
`of CoreBuilder are applied to Amara, there's certainly no
`reason to believe that the logging function of Amara would be
`dropped all of a sudden. There's every expectation that the
`logging function of Amara would be controlled by the control
`plane configurations of CoreBuilder. And that rebuts the
`argument that Cisco is making regarding the combination of
`CoreBuilder and Amara.
`Cisco's argument depends on an assumption that,
`
`
`
`17
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`for some reason, adding CoreBuilder's control plane
`configurations to Amara would result in deleting the logging
`function of Amara and there is no basis for that position
`stated anywhere.
`And our expert, Dr. Lin -- now this is now slide
`20 -- lays out in detail why one skilled in the art would
`combine -- be motivated to combine CoreBuilder with Amara
`and to use the CoreBuilder configurations to control Amara's
`policies. And there is no -- no argument and no support for
`Cisco's position that somehow logging would be deleted from
`that.
`
`The third issue that was a question raised by
`Cisco's briefing is a question whether CoreBuilder is prior art.
`I think that issue is very well addressed in the briefing. I'll
`be happy to answer any questions from the panel. But,
`fundamentally, it's quite clear from the evidence that
`CoreBuilder was shipped for three years to many customers
`throughout the United States and that they -- it was shipped
`without any confidentiality restrictions. And, in fact, the
`manuals for the product that the CoreBuilder manual would be
`sent with were shown on the 3Com website, also, at the time,
`with the Wayback Machine. So, I think that evidence is quite
`
`
`
`18
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`sufficient to establish public accessibility. Anybody who
`bought that product got that manual.
`So, the second instituted ground I'd like to turn to
`unless the panel has any questions regarding the first ground
`-- the second ground is the question of Amara, CoreBuilder,
`plus Moberg, and that applies to claims 7, 23, and 59. And
`we're now at slide 32.
`The first issue, obviously, we are reserving for the
`end period, so I will not cover that now. The second issue
`with regard to Moberg is whether it, in fact, discloses
`distributing those control plane processes to a secondary
`processor. And that's the issue to which I'd like to turn now.
`I've shown now on claim 31 the language of the
`claims that are -- that are at issue. And now at slide 32 -- 52,
`sorry, is the disclosure of Moberg, Exhibit 1005 at figure 3,
`and, ultimately, the Lin declaration at paragraph 71. And this
`is the core aspect of the Moberg reference that we're relying
`on.
`
`The Moberg reference tells you what the primary
`processor does. And the primary processor is responsible for
`such routine tasks as routing table computations and network
`management. And, so, the question is are those types of --
`
`
`
`19
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`first question is are those types of tasks control plane tasks.
`That's the first question. I don't think there's a dispute about
`that.
`
`Their expert, Dr. Almeroth, at Exhibit 2006,
`paragraph 92, says explicitly that tasks such as routing table
`computations and network management would be typically be
`reserved for slow path processing by the control plane.
`So, now we have, I think, agreement that the
`primary processor is doing control plane processes. And, so,
`now the question is would those types of tasks be seconded or
`offloaded to the secondary processor.
`And the Moberg reference -- now we're at slide 54
`-- is quite clear about that -- it's at column 2, lines 25 to 30 --
`the secondary processor being able to offload work from the
`primary processor, thus, making use of both processors
`simultaneously. The present invention addresses such needs.
`And I think it's important to note that the portion
`just above that cites another benefit of having the secondary
`processor, which is if the first processor goes down, becomes
`inactive for some reason, the secondary processor can take its
`place completely.
`So, there's two benefits to the secondary processor
`
`
`
`20
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`cited by Moberg. One is it's a backup to the primary. It can
`do everything the primary was doing if it, the primary, goes
`down. And the second is even if they're both going to be
`running simultaneously, you can offload some of the
`functionality of the primary processor to have them running
`more efficiently.
`Both of those have the secondary processor doing
`some or all of what the primary processor was doing. And
`what the Moberg reference is teaching at column 4 is the
`primary processor is doing control plane tasks.
`So, there is, I think, undeniable that the secondary
`processor is being taught in Moberg as doing the tasks the
`primary processor was doing, which are control plane tasks.
`So, now, what is Cisco's response? We're now at
`slide 55. Slide 55 says, well, the only tasks that are shown as
`being done at the control plane processes is the primary CPU.
`And that's half right but not enough right. It's half right that
`it says the primary CPU is doing control plane processors --
`that's the part I just showed you -- but it's also true that the
`secondary processor is doing the things the primary processor
`was doing, either as a backup when the primary goes down or
`to take part of what the primary was doing.
`
`
`
`21
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`
`There is no disclosure in Moberg of the primary
`processor doing something other than control plane processes
`or the secondary processor doing anything other than the
`control plane processes that the primary was doing.
`So, Cisco's argument is ignoring the part of
`Moberg that teaches the secondary processor does what the
`primary one did, which were control plane processes.
`There is also nothing in Moberg -- we're now at
`slide 56 -- that limits in any way processes being offloaded to
`the secondary processor from being something other than
`control plane. There's no disclosure of anything -- and, in
`fact, it's unlimited.
`We've got various portions of Moberg cited on
`slide 56, first at column 2, that's the portion we've had before,
`the portion with reference to any processing at control 8,
`which the Board relied upon in its institution decision, and
`also at column 6, the description of the tasks being performed
`is a list of projects or functions that are to be assigned to and
`performed by the secondary processor. Those functions and
`products may include functions and projects typically
`performed by the primary processor, which the Moberg
`reference teaches are control plane processes.
`
`
`
`22
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`
`So, there is -- the disclosure of Moberg, we
`believe, is abundantly clear about this.
`Now I'd like to turn to Cisco's. This is Cisco's
`slide 35. Cisco's slide 35 is their attempt to argue that
`Moberg does not distribute, as they say in the title, control
`plane processes. And you look at the portion above and it's
`saying some functions that are conventionally the duty of the
`primary processor.
`But the main part they're relying upon in their
`slide 35 is from column 5, which talks about communication
`intensive tasks being offloaded as packet switching and
`filtering and media control and management. And, so, Cisco's
`argument is, ah-ha, this tells you what is being delegated from
`the primary processor and it's not those types of control plane
`processes.
`
`Well, Cisco's argument again is only half right but
`it's the wrong half. That portion that they're citing at column
`5 is not, repeat not, discussing what's allocated between the
`primary processor and the secondary processor, which is the
`issue for the claims. It is discussing, instead, what is the
`division of labor between the primary processor and the
`so-called independent processors, which are not the primary
`
`
`
`23
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`processors.
`
`And, so, Cisco's arguments actually proves our
`point. Cisco's argue -- this portion of the specification says
`the primary processor is limited to things like control plane
`processes. The independent processors get other tasks. And
`the secondary processors are doing what the primary processor
`would be doing.
`Now, the independent processors are plainly not --
`not the secondary processors. If you look at column 5 of the
`Moberg reference, the very portion that Cisco cited, it's quite
`clear that those are different. They are an interface -- part of
`high-speed interface 162. They are not the secondary
`processor that is issued in this proceeding.
`And when you look at Moberg figure 3, you see
`that 162 is way there in the upper right -- this is our slide 54
`again -- whereas, the primary and secondary CPUs are down
`in the lower left -- very, very different. It's talking about a
`completely different delegation of responsibilities.
`The -- there is complete delegation between
`primary and independent. There is sharing between primary
`and secondary. And what's shared is the control plane
`processes that are described as being the burden of the
`
`
`
`24
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`IPR2016-00303 (Patent 6,377,577 B1)
`IPR2016-00306 (Patent 7,023,853 B1)
`IPR2016-00308 (Patent 7,162,537 B1)
`IPR2016-00309 (Patent 7,224,668 B1)
`
`primary processor.
`The third instituted ground relates to Hendel.
`We've shown on slide 57 what the claims at issue are. The
`issue is whether the control plane port services are
`distributed. And the whole point of Hendel is to distribute
`services. That is its point. And we've made, I think, quite
`clear in the briefing that Amara has central control over those
`services and that Hendel -- and now we're at slide 60 --
`teaches distribution of those services in exactly the way the
`claim is referring.
`Cisco's argument is, well, it doesn't teach the
`distribution specifically of something called a control plane
`service. What Hendel teaches unambiguously is the
`distribution of all services without regard to what type it is.
`And it teaches so for the benefit of scalability, which is,
`obviously, something that the engineers would be
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
