`U.S. PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`CISCO SYSTEMS, INC.
`Petitioner,
`
`v.
`
`EGENERA, INC.
`Patent Owner.
`____________
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`____________
`
`Record of Oral Hearing Held:
`July 25, 2018
`____________
`
`Before KRISTEN L. DROESCH, CHARLES J. BOUDREAU and
`MELISSA A. HAAPALA, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`THEODORE M. FOSTER, ESQUIRE
`DAVID L. MCCOMBS, ESQUIRE
`Haynes and Boone LLP
`2323 Victory Avenue, Suite 700
`Dallas, Texas 75219
`
`JAMES E. QUIGLEY, ESQUIRE
`JOHN B. CAMPBELL, ESQUIRE
`McKool Smith
`300 West 6th Street, Suite 1700
`Austin, Texas 78701
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`
`
`
`
`
`
`The above-entitled matter came up for hearing on Wednesday, July
`
`25, 2018, commencing at 12:59 p.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`2
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE DROESCH: Please be seated. Good afternoon. We're here for the
`oral hearing for IPR 2017-01340 between Petitioner, Cisco Systems and
`Egenera. I'm Judge Droesch. We're joined by video with Judge Haapala
`from the Denver satellite office and Judge Boudreau from the San Jose
`satellite office. Each party has 60 minutes total time for arguments.
`Because Petitioner bears the burden of showing unpatentability, Petitioner
`will open the hearing by presenting its arguments first. Petitioner may also
`reserve some of its time for rebuttal; and following Petitioner's arguments,
`Patent Owner will proceed; and then, if applicable, Petitioner may present its
`rebuttal arguments.
`
`Counsel for Petitioner, whenever you're ready, please state your name
`for the record and introduce your co-counsel and anyone else in attendance
`today; and then you may begin your arguments after the introductions.
`
`MR. MCCOMBS: Good afternoon, Your Honors. I'm David
`McCombs here on behalf of Petitioner, Cisco Systems. With me is my
`partner, Theodore Foster, who will be making the presentation today; and
`also, we have one of Cisco's attorneys, Peter Magic, in attendance with us.
`Thank you.
`
`JUDGE DROESCH: Thanks.
`
`MR. MCCOMBS: I'll turn it over to Theo.
`
`JUDGE DROESCH: Okay.
`
`MR. FOSTER: Good afternoon. May it please the Board, Theo
`Foster on behalf of Petitioner, Cisco Systems. Looking at slide 3, there are a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`3
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`few topics that I'd like to discuss here this afternoon, and the first of those is
`Egenera's attempt at swearing behind the Ma reference, and their failure to
`do so. As we know, swearing behind requires both conception and
`diligence, and Egenera's evidence fails on both counts. I think this case is
`somewhat notable. There are declarations from two named inventors,
`neither of them in their declarations claims to have conceived of the subject
`matter prior to Ma's filing date; and neither of them claims to have been
`diligent in pursuing those ideas up to the filing date of their non-provisional
`application. So for that reason alone, the fact that the named inventors
`themselves don't even claim to have conceived of the claimed concepts or
`been diligent in pursing them, for that reason alone, this swear-behind
`attempt would fail.
`
`But moving on and looking at slide 4 -- and looking, specifically, at
`some of Egenera's evidence presented on this topic -- slide 4 shows a portion
`of the Patent Owner's Response at page 19 where they address their alleged
`conception evidence relating to the failover logic limitation. In particular,
`the logic to assign the virtual MAC address of the failed processor to the
`processor that replaces the failed processor.
`
`And on this point, Egenera says well, back above in the earlier
`analysis for portion 1(c) they allege that they showed that their node
`configuration includes a virtual MAC address; but if we move to slide 5 --
`and slide 5 here has the Patent Owner's Response at page 11 where they
`address what they label as limitation 1(c) -- and their evidence does not
`support their allegation that the inventors -- the named inventors -- had
`conceived of the virtual MAC address as being part of a node configuration.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`4
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`Instead, what their evidence says is that a Giganet driver code will assign an
`Ethernet 48-bit media access control, or MAC address, in place of a
`hardware-provided MAC address; but it's not described as being part of a
`node configuration.
`
`And if we move on and look at slide 6, the evidence that Egenera
`provided from what they labeled their corroboration documents, actually
`shows that this idea of a MAC address being moved upon failover from
`machine-to-machine, that it appears the named inventors had not yet
`conceived of that idea prior to Ma's filing date. Looking at slide 6 -- and this
`is in the middle -- there's a portion of Egenera's Exhibit 2012, from page 6,
`where there's discussion of the format of a simulated MAC address -- and it
`says that's to be specified; so, obviously, they were still figuring out how
`they were going to handle MAC addresses, if at all. But it goes on and it
`says that the simulated-MAC address "will include the node number." So,
`the node number, the number of a node, is particular to a MAC address for
`that node. Obviously, this implies that any simulated MAC address that they
`were conceiving of was going to be specific to a particular node, not
`something that could be transitioned, as the claim calls for, from one
`computer processor to another computer processor.
`
`So, the conception evidence is simply not here and, in fact, what
`Egenera has put forward, affirmatively shows that they had not yet come
`upon the idea of virtual MAC addresses that would be re-assignable between
`nodes or between computer processors. Even if Egenera had evidence of
`conception for all of the claim limitations -- and, I think, I've just
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`5
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`demonstrated they don't -- even if they had that, of course, they also have to
`show diligence.
`
`And if we look at slide 7, Egenera's evidence regarding diligence is
`wanting as well. In their Patent Owner's Response, the attorneys assert that
`Egenera was working on the claimed subject matter from November 2000
`until January 2002 -- and I believe that's in reference to the January 4, 2002
`filing date of their non-provisional application. But the declarations from
`the named inventors don't support that allegation from the attorneys; and, in
`fact, the declaration of named inventor, Scott Geng, merely states that the
`group was working "during the late 2000 time period and into 2001." So,
`there's not even a claim or a statement to support the allegation of work into
`2002. It was merely from an allegation of work from late-2000 until
`sometime in 2001, but ending, apparently, well before the January 2002
`filing date of the non-provisional application. So, the diligence aspect of
`this swear-behind attempt is also lacking.
`
`With that, I believe Ma remains prior art, and I'd like to move on
`looking at slide 8, to the second topic, and that's the obviousness of
`combining the Aziz and Ma references.
`
`If we go to slide 9, I have here a quote from a treatise, just
`background treatise, on high availability systems and servers failover
`concepts -- the general technology space that we're dealing with here of
`network computing -- and Marcus is Exhibit 1009 -- we filed a second copy
`as Exhibit 1024 in response to an objection from Egenera. Pages 88 and 89
`of those exhibits contain background information that a person of ordinary
`skill in the art would have known having worked and been familiar with
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`6
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`server systems, been familiar with the failover concepts that were out there
`and were known in the industry; and what Marcus describes is a known
`problem that can occur when a server fails over from a failed node to a
`replacement, and that is that the clients that were accessing that server will
`have cashed a mapping between the IP address and the MAC address of that
`server that has now failed; and that mapping can become out of date or stale
`incorrect depending on how that failover happens.
`
`If the client continues to rely on that stale information, of course, they
`will continue to send messages that won't reach the replacement server if the
`replacement server has a different IP address or MAC address. And so, this
`problem was known; and as Marcus demonstrates, the solution to it was also
`known. As we see at the bottom of slide 9, one solution is to move the
`MAC address, as well -- move the MAC address from the primary to the
`secondary node; move it from the failed computer to the replacement
`computer.
`
`So, Marcus is describing this general background information and
`knowledge about how failover works, how networks work, and how servers
`and clients interoperate that a person of ordinary skill in the art would have
`brought with them to their understanding of Aziz, and their understanding of
`Aziz's limitations -- and, in particular, that Aziz being a system that is
`performing failover -- Aziz's system is susceptible to this stale IP/MAC
`address mapping problem, and Ma, of course, is our secondary reference that
`teaches the known solution to that; and, in particular, Ma is providing that
`solution in a virtualized network context. And so, since Aziz is describing
`virtual networking and would suffer from this known problem, we believe it
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`7
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`would be obvious -- and our expert, Dr. Shenoy, supported us on this -- that
`it would have been obvious to apply the known solution of Ma -- of
`assigning IP and MAC addresses together to a replacement server during a
`failover operation. And so, that combination then comes together with Aziz
`having most of the claim limitations and then Ma coming in to teach this
`known solution to a known problem that a person of ordinary skill in the art
`would have recognized Aziz suffers from.
`
`I'd like to move on to slide 13 and the next topic; and that is Aziz's
`teaching about failover and the automation of the failover operation.
`
`JUDGE HAAPALA: Counselor, before we move on, going back to
`Ma's teaching, the virtual MAC address on the active commander, the active
`commander is a switch and not a processor, is that right?
`
`MR. FOSTER: So, looking at slide 11, I believe might be helpful for
`this question. So, Ma's teaching is that, yes and what it terms as an active
`commander -- well the commander activator is a separate thing -- the active
`commander is the device that is in ownership or possession of the IP and
`MAC addresses -- it's the device that's functioning in the role and if that
`device fails then Ma teaches assigning those addresses to a replacement
`device. Now, in Ma -- Ma describes that in the context of what Ma terms a
`network device -- Ma's specific example is, as you suggested in the context
`possibly of a switch or a router, but Ma is not limited to that; and if we move
`to slide 20, Ma's teaching is more general than that and its concept of what a
`network device could be is much broader than just switches, bridges, and
`routers as Egenera is arguing.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`8
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`Looking at the second quote on slide 20 -- this is from Ma, column 2,
`
`starting around line 29 -- Ma refers to "hosts or other network devices"
`plainly indicating that hosts are also within the concept of network devices
`within Ma. And if we look at figure 1(a) of Ma, also on slide 20, we can see
`that the host 5(a), 5(b), and 5(k) are depicted as ordinary computers; and so,
`the teachings of Ma are not restricted simply to switches but, in general, to
`all kinds of devices found in a network. Judge Haapala, does that answer
`your question?
`
`JUDGE HAAPALA: Yes, thank you.
`
`MR. FOSTER: Thank you. So, moving back to slide 14 and Aziz's
`teaching of automated failover, Aziz describes this in a couple of different
`ways. The first I have here a quote from Aziz, column 7, line 8 where Aziz
`talks about what it's going to do with its computing elements; and it
`describes that it's going to have a pool of unused or idle computing elements,
`and that those can be assigned to a Virtual Server Farm, a VSF in Aziz's
`terminology -- which is basically a virtual network. An idle element can be
`assigned to a Virtual Server Farm "to deal with failures of a particular
`computing element in a VSF."
`
`So, Aziz is contemplating a failover situation and a failover capability
`with this language; and if we continue on, looking at Aziz column 3, starting
`around line 17, Aziz describes the process that it's going to use and the
`technology it's going to use for moving those computing elements from the
`idle pool into a VSF, and it describes doing that "under program control."
`So, this is the teaching that -- this process of employing or deploying a spare
`computing element to replace a failed computing element -- that's done
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`9
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`under program control; and Aziz emphasizes the automated nature of this as
`we see in column 8 around line 66, and then spilling over to the top of
`column 9, Aziz states that "a particular VSF, or Virtual Server Farm, is not
`subjected to manual reconfiguration." So, Aziz is very specific that its
`process for managing Virtual Server Farms is not manual; it is automated.
`
`And if we move on and look at slide 15, Aziz actually disparages
`manual processes repeatedly. Looking at column 2 of Aziz, line 49, Aziz
`refers to how human error in configuring a new server can cause the entire
`server farm to malfunction; so, obviously, a bad result. In column 1, line 50
`it refers to prior art solutions that suffered from "manual and error-prone
`administrative steps." And then at the end of Aziz, it touts its advantages
`over conventional manual approaches to constructing and managing server
`farms. So, Aziz is very critical of manual processes, and is emphasizing
`with this language the automated nature of its solution, and the fact that by
`deploying idle elements to deal with failures under program control, Aziz is
`teaching automated failover techniques.
`
`The next topic that I'd planned to talk about was the teaching of
`virtual MAC addresses for computer processors; and Judge Haapala, I think
`in answering your earlier question, I addressed most of what I was going to
`say on this. I would just point out that Egenera's arguments relating to this
`concept --
`
`JUDGE HAAPALA: Counselor, are you on a particular slide?
`
`MR. FOSTER: Yes; I'm sorry, I'm on slide 19.
`
`JUDGE HAAPALA: Thank you.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`10
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`MR. FOSTER: Egenera's arguments relating to the claimed virtual
`
`MAC addresses for computer processors. Egenera's arguments on that rely
`entirely on their misunderstanding or misinterpretation of the Ma reference
`in their assertion that Ma is somehow limited to only switches, bridges, and
`routers when, as I've discussed earlier, in fact, it's very clear that it's more
`broad than that. I would also point out that Ma, at column 2, line 40, Ma
`refers to a host or client, and then in parentheses, it says, i.e., the network
`device. So it's renaming network device and indicating by network device, it
`also means hosts and clients. It's very clear that it's not just switches,
`bridges, and routers.
`
`Looking a slide 24, the final topic that I wanted to address this
`afternoon relates to the claimed construction for Virtual Local Area
`Communication Network. And looking at slide 25, the Board at institution
`addressed this limitation -- this phrase -- and was not persuaded by Egenera's
`arguments then that the term should be interpreted as requiring the entire
`network be simulated by software. The board rejected that view -- noting
`that the '044 specification refers to the hardware components and the
`physical network underlying the claimed technology. And looking a slide
`26, Egenera has simply repackaged this argument and dressed it up in some
`new clothes, but fundamentally, I think it's still the same argument. Egenera
`in their Patent Owner Response, at page 34 -- this is again, on slide 26 --
`Egenera is now arguing that this Virtual Local Area Communication
`Network should be understood to require using software to implement
`network equipment itself. So, this is simply repackaging this argument that
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`11
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`the entire network itself is software implemented, and that's, again,
`inconsistent with the '044 specification.
`
`Looking at slide 26 and the '044 specification at column 3, around line
`21, it refers to the two switch fabrics which are the network components and
`the two switch fabrics being contained in a single chassis, strongly
`indicating the physical nature of those; and then at column 3, line 57, it goes
`on and describes the switch fabrics as including devices such as a NIC-
`CLAN 1000 and a CLAN 5300 switch; and we asked Peter Manca, one of
`the named inventors about those devices -- what are the NIC-CLAN 100 and
`the CLAN 5300 -- and in his deposition, this is Exhibit 1034, page 39,
`starting at line 15 -- he confirmed that those are, indeed, physical
`components. So, Egenera's argument that it's the network equipment itself
`that is being software simulated is inconsistent with the disclosure of the
`'044 specification, and I would encourage the Board to reaffirm the initial
`construction for Virtual Local Area Communication Network is merely
`requiring partial simulation; and to that idea and the partial simulation
`looking at slide 28, either under the Board's initial construction or even
`under Egenera's proposed construction, Aziz is very clear that it does teach
`software simulated network equipment.
`
`For example, looking at Aziz's figure 3, you can see that element 302
`is a computing element that has been configured in a Virtual Server Farm to
`act as a load balancer in a firewall; and Aziz describes how that load
`balancer and firewall operate. For example, looking at column 18, starting
`at line 16, Aziz describes how all of the computing elements -- they're just
`computer processors with network and storage connectivity -- and as Aziz
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`12
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`says, they're fungible, right; they're completely interchangeable and inter-
`replaceable. They only assume a specific processing role when they are
`connected to a particular Virtual Server Farm and they load the software
`that's been assigned to them. And so, it's the software that is making a
`computing element act as a firewall in Aziz in figure 3.
`
`In Aziz, at column 9, lines 52-54, it reiterates that, for example, a
`CPU can take on a particular role by be pointed to and then loading
`"dedicated load balancing/firewalling software." So, here we have Aziz
`describing network equipment such as a firewall or a load balancer that's
`being simulated or emulated, being assigned to that role through the use of
`software. So, here's our partial simulation of network equipment.
`If there are no further questions from the Board --
`JUDGE HAAPALA: I have nothing further.
`
`MR. FOSTER: Okay; very good.
`
`JUDGE DROESCH: I have nothing.
`
`MR. FOSTER: I encourage the Board to reaffirm its initial findings
`
`and find all of the claim limitations taught by the prior art and the claims
`obvious and unpatentable as put forward in the Petition. I'll reserve the
`remainder of my time for rebuttal.
`
`JUDGE DROESCH: Thank you.
`
`MR. FOSTER: Thank you.
`
`JUDGE DROESCH: Whenever you're ready to begin, please
`introduce yourself and your co-counsel, and then whenever you're ready,
`begin.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`13
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`MR. QUIGLEY: Good afternoon, Your Honors. James Quigley of
`
`McKool Smith here on behalf of Egenera, Inc. Also with me is John
`Campbell, also with McKool Smith.
`
`This is not a case with allegations of anticipation; this is not a case
`where Cisco is suggesting that there's an individual reference that's teaching
`every limitation in the '044 Patent; instead this is a case of obviousness. As
`we see here on slide 2, in this case, Cisco is suggesting that the Ma reference
`in combination with Aziz renders obvious the independent claims of the '044
`Patent, claims 1 and 4; but, in fact, that combination of Ma with Aziz fails to
`render the claims of the '044 Patent obvious.
`
`Slide 3 has the three independent reasons why Cisco's invalidity or
`obviousness challenge fails here in this case. First reason -- the '044 Patent
`pre-dates Ma. The '044 Patent and its claimed inventions were conceived of
`more than a month before the Ma reference was filed for. The '044 Patent
`inventions were diligently reduced to practice and Ma's not prior art. If Ma's
`not prior art, Cisco's entire challenge fails.
`
`The second independent reason that Cisco's obviousness challenge
`fails is that the combination of Ma with Aziz fails to render obvious the
`claimed virtual MAC addresses for the claimed computer processors.
`Instead, what we have with Cisco's Ma reference is a reference that refers to
`"virtual MAC addresses" in the context of network devices -- switches,
`bridges, and routers -- and not the claimed computer processors. In fact --
`
`JUDGE HAAPALA: Counselor, even if that's true, I'm going to
`interrupt you here -- even if that's true, is there a difference in how a switch
`or router would use a MAC address, virtual MAC address, as opposed to a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`14
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`processor? Isn't the virtual MAC address just an address used to
`communicate? Is there some difference with the virtual MAC being
`assigned to a switch or a router?
`
`MR. QUIGLEY: Yes, I do, Judge Haapala, think that there is a
`difference between Ma's "virtual MAC address" that's being used for these
`network devices and then the MAC addresses that are being used in the '044
`Patent. And the difference here is that the Ma patent is addressing a
`different problem with these network devices than with a computer
`processor in the context of the '044 Patent; and it's addressing that problem
`in a different way, with a different sort of solution.
`
`JUDGE HAAPALA: Okay; Counsel, that's not what I'm asking. I'm
`asking specifically about the virtual MAC address and if there's a difference
`on how a switch or router uses a virtual MAC address and a processor uses a
`virtual MAC address.
`
`MR. QUIGLEY: I think, in the context of this case, with these
`network devices in Ma, like Ma’s switches, yes there is a difference in how
`the MAC address is being used. Ma is dealing with a virtual MAC address
`for an entire group of devices; it's not even assigned to an individual device.
`
`JUDGE HAAPALA: My understanding though is that it's being used
`to communicate with other devices, correct? The active commander's virtual
`MAC address is being used to communicate with other devices?
`
`MR. QUIGLEY: In some way it's involved in the communication
`process in Ma, yes.
`
`JUDGE HAAPALA: Okay; thank you.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`15
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`MR. QUIGLEY: And so, the third independent reason that the '044
`
`Patent is not rendered obvious by Cisco's prior art is that the combination of
`Ma with Aziz fails to render obvious the claim to automated failover.
`
`Moving on to slide 4, the first independent basis that Cisco's
`obviousness challenge fails is that Ma is not prior art. The '044 Patent was
`conceived of before Ma; it was diligent, reduced to practice; and without
`Ma's prior art Cisco's challenge fails.
`
`We see on slide 5, that Ma has a filing date of December 15, 2000; but
`moving on to slide 6, the '044 Patent and its inventions were conceived of by
`November 7, 2000. How do we know this? Well, we've actually been able
`to go back and get internal Egenera documents from back in the 2000 time
`period. These internal Egenera documents related to a product that the
`inventors were working on called the Interframe. I'm almost certain you
`hadn't heard of the Interframe before this case -- it was the internal name for
`a product that later became as the BladeFrame when it was released -- but
`these documents related to the Interframe show that the inventors had
`conceived of each and every limitation in the '044 Patent by November 7,
`2000.
`Dr. Jonathan Chao, an engineering professor at NYU, has looked at
`
`these documents and he's told us that those documents show the support for
`the claims of the '044 Patent. On the other hand, Cisco has offered no expert
`testimony related to these conception documents. In terms of the dates of
`these documents -- of these conception documents -- we're not relying solely
`on inventor recollection; we're not relying solely on the dates listed on the
`documents; and so we've actually been able to go back into the repositories
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`16
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`where these documents have been housed for a number of years and look at
`the metadata; and the metadata has told us that each of these documents was
`last modified on or before November 7, 2000.
`
`So, in this case, Cisco really only disputed in its Reply Brief two
`limitations -- whether or not two limitations in each of the independent
`claims were supported by these conception documents. The first one, as we
`see on slide 6, is this configuration logic limitation. Cisco didn't address that
`configuration logic limitation this afternoon. I don't plan to address it unless
`any of Your Honors would like hear about it.
`
`JUDGE HAAPALA: I'm more interested in the failover logic myself.
`
`MR. QUIGLEY: Yes, Your Honor. So, that second limitation is here
`on slide 6 -- it's that failover logic limitation; and Cisco is contesting
`whether or not this failover logic limitation is shown in these conception
`documents. So before we jump into conception documents, I want to give
`you a bit of background on the Interframe. So, I'm turning now to slide 9.
`
`So, like I said, the Interframe is something you probably hadn't heard
`of by 2000. It was an internal name for a product that ended up being
`released as the BladeFrame. The Interframe was a computer processing
`platform. It was a platform that was connectible to both an external storage
`and external communication network; and we can see here on slide 9 an
`annotated version of figure 1 showing us how this grey Interframe platform
`could be connected to this yellow and blue communication and storage
`network.
`
`In slide 10, I've actually peeled away that grey highlighting for the
`Interframe platform to show you what's underneath in some of those relevant
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`17
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`components that are going to be discussed this afternoon with respect to
`failover logic. On the left-hand side of slide 10, we have in purple the
`processing or application nodes. Sometimes these are referred to as
`processing blades in these conception documents. These were the compute
`resources that are a part of this Interframe platform.
`
`On the middle right-hand side of slide 10, we have in red the
`Interframe controller node. This Interframe controller node was how the
`Interframe platform was able to communicate with these external and
`communication networks; and in the middle we see in green the Giganet
`internal network. The Giganet internal network within the Interframe is
`what allowed those processing application nodes to communicate with that
`Interframe controller node.
`
`Jumping ahead to slide 14 and that failover logic limitation that we
`were just discussing -- that limitation reads, the failover logic including logic
`to assign the virtual MAC address of the failed processor to the processor
`that replaces the failed processor. We see here on slide 14 from Egenera's
`Patent Owner Response, a description of how the Interframe platform
`included failover logic such as on the Interframe controller node that we just
`highlighted in red, which when a processing blade or node failed -- those
`were highlighted in purple -- caused another blade or node to replace it,
`which included taking on the failed blade or node's configuration and
`resources. Part of those resources included a virtual MAC address. Now the
`documents actually bear this out. The documents bear out that there's an
`automatic failover process that was planned for this Egenera Interframe
`product.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`18
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`Now, moving on to slide 16, we've got to take a step back with this
`
`failover logic and remember that the failover logic in the claims is
`addressing when there's a failure, we've got to allocate a new computer
`processor to take the place of a failed processor. We've got to do that
`automatically. We see on the left-hand side of slide 16, from Exhibit 2024, a
`document entitled Egenera Interframe Architecture, a quote that reads "the
`health of an application node is continuously assessed by management
`software through heartbeats. Management software can notice when an
`application node has crashed or hung and can initiate recovery behavior."
`What this is telling us is the software on the Interframe controller node is
`continuously monitoring the health of these processing application nodes.
`It's doing that through this heartbeat mechanism; and it's able to determine
`when there's been a crash, a hang, or some type of failure; and when that
`failure occurs, it's able to take some pre-planned, pre-specified route.
`
`On the right-hand side of slide 16, also from Exhibit 2024, we see that
`the application nodes have configurable behavior in response to certain
`events such as that failure we were just talking about. The response can be
`something like automatically booting a new processing node with a specified
`configuration. Now, I don't have these documents up on a slide, and I don't
`have the ELMO here -- I'm sorry Judge Droesch -- I'm just not connected in
`a way that I can show you -- but Exhibit 2009 and 2010 recited in Patent
`Owner's Response, pages 15-17 -- and there are some relevant excerpts to
`this automatic failover, this automatic replacement of a failure processing
`node.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`19
`
`
`
`Appeal IPR 2017-01340
`Patent 6,971,044 B2
`
`
`Exhibit 2009, at the bottom of page 2 in the left-hand column reads
`
`spare application processors can be configured as standby nodes, and can be
`rapidly booted with the same software
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
