`
`
`
`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