`
`
`571-272-7822
`
`
`
`
`
`
`
` IPR2015-00810 Paper No. 43
` IPR2015-00811 Paper No. 43
`IPR2015-00812 Paper No. 42
`July 6, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`----------
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`---------
`APPLE, INC.,
`Petitioner,
`V.
`VIRNETX INC.,
`Patent Owner.
`----------
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`--------
`Wednesday, June 8, 2016
`
`Before HONORABLE KARL D. EASTHOM, HONORABLE
`JENNIFER S. BISK, and HONORABLE GREGG I. ANDERSON,
`Administrative Patent Judges.
`
`Hearing in the above matter was held at the U.S. Patent &
`Trademark Office, Patent Trial and Appeal Board, Madison Building, 9th
`Floor, Hearing Room A, 600 Dulany Street, Alexandria, Virginia, at
`1:30 p.m.
`
`
`Reported by Elizabeth Mingione, RPR and Notary Public for
`the Commonwealth of Virginia.
`
`
`
`A P P E A R A N C E S O F C O U N S E L:
`
`ON BEHALF OF PETITIONER, APPLE INC.:
`
`
`SCOTT BORDER, ESQUIRE
`THOMAS A. BROUGHAN, III, ESQUIRE
`SIDLEY AUSTIN, LLP
`1501 K Street, Northwest
`Washington, D.C. 20005
`(202) 736-8314
`Tbroughan@sidley.com
`Sborder@sidley.com
`
`ON BEHALF OF PATENT OWNER, VIRNETX, INC.:
`
`
`JOSEPH E. PALYS, ESQUIRE
`DANIEL ZEILBERGER, ESQUIRE
`CHETAN BANSAL, ESQUIRE
`NAVEEN MODI, ESQUIRE
`PAUL HASTINGS, LLP
`875 15th Street, Northwest
`Washington, D.C. 20005
`(202) 551-1996
`Josephpalys@paulhastings.com
`Chetanbansal@paulhastings.com
`Naveenmodi@paulhastings.com
`Danielzeilberger@paulhastings.com
`
`
`
`2
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`P R O C E E D I N G S
`
`(1:30 p.m.)
`JUDGE BISK: Please be seated. Judge
`Anderson, can you hear us?
`JUDGE ANDERSON: I can. Thank you.
`JUDGE BISK: Okay. Great. So this is a
`hearing for Apple, Inc. versus Virnetx, Inc. And it's three
`separate cases that we are hearing together,
`IPR2015- 00810, 2015- 00811 and 2015- 00812.
`As you can see, we have Judge Anderson
`joining us on video from Denver. Or where are you
`joining us from? Are you in California or Denver today?
`JUDGE ANDERSON: I'm in California today.
`JUDGE BISK: California. So please be aware
`of that and try to direct all of your speaking into the
`microphone. Otherwise, Judge Anderson can't hear you.
`He also can't see the board. So if you are
`using your slides, be sure to tell us which slide number
`you are on. And with that, we have 40 minutes per side.
`And can the parties tell us who's here for each party.
`MR. BORDER: Yes, Your Honor. Scott
`Border for Petitioner, Apple. And with me is Tom
`Broughan.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`3
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`MR. ZEILBERGER: Your Honor, Daniel
`Zeilberger for patent owner; lead counsel, Joseph Palys;
`Naveen Modi, chief counsel.
`JUDGE BISK: Okay. And, Petitioner,
`whenever you are ready. Did you want to save time for
`rebuttal?
`
`MR. BORDER: Yes, Your Honor. I plan on
`saving about 15 minutes.
`JUDGE BISK: Okay.
`MR. BORDER: May I approach with
`demonstratives?
`JUDGE BISK: Sure.
`MR. ZEILBERGER: Your Honor, would you
`like us to provide you our demonstratives as well?
`JUDGE BISK: Sure. Whenever you are ready.
`PRESENTATION FOR PETITIONER
`MR. BORDER: Good afternoon, Your Honors.
`May it please the Board. We are here to
`discuss three proceedings involving two patents owned by
`Virnetx, the '705 and the '009 patents.
`There are two primary prior art references
`we'll be discussing today, Exhibit 1007, a U.S. patent to
`Beser, and Exhibit 1009, which is an Aventail reference
`publication. We'll also be discussing RFC 2401, which is
`Exhibit 1008.
`
`
`
`4
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`Can you change to slide 15, please.
`Very quickly I want to go over Claim 1 of the
`'705 patent. The '705 describes a method of creating an
`encryptic communications channel between a client and
`target device, and comprises three steps.
`The first step is intercepting from the client
`device a request to look up the IP address. The second
`step is determining whether that request corresponds to a
`device that accepts an encrypted channel connection. The
`final step is in response to that determination, providing
`certain provisioning information to initiate the creation of
`the encrypted communication channel.
`The basic steps of Claim 1 of the '009 patent
`are similar, but they are from the point of view of a client
`device, rather than a server. There are some distinctions.
`I'll touch on those shortly.
`On slide 3, I've created a brief road map of the
`issues we are going to discuss today with respect to the
`'810 and '812 proceedings. There are four primary issues
`I want to address.
`But, first, before I get into these, I want to
`walk through the combination of Beser and RFC 2401, and
`then I'll focus on these issues of dispute. Slide 4, please.
`This slide includes two figures from Beser and
`one excerpt from RFC 2401. At the top left is Figure 1 of
`
`
`
`5
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`Beser. And it shows the basic architecture of the
`disclosed system.
`Beser describes a method of creating a tunnel
`between two devices, two end devices over a public
`network. The tunnel permits those devices to
`communicate anonymously over a public network. The
`tunnel is created with the assistance of first-party network
`device 14, second- party network device 16, and trusted
`third- party device 30.
`Now, to the right of the screen is Figure 6 in
`the Beser patent. And it describes the basic process the
`Beser method undergoes in order to establish this
`tunneling association. The originating device, that's 24,
`device 24, generates a request for a tunneling association
`to -- and that request includes a domain name of device
`26. That request is received first at the first network
`device 14.
`
`There, the first network device 14 evaluates
`the request and forwards it to the trusted third- party
`network device 30. In both circumstances, the request
`pertains to device 26, but is received at either device 14
`or device 30. After --
`JUDGE BISK: So which are you saying is
`intercepting 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
`
`
`
`6
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`MR. BORDER: Well, Your Honor, what we
`are pointing to are two different interceptions in this -- in
`the Beser method. First, the device 14 intercepts the
`request, and then device 30 also intercepts the request.
`JUDGE BISK: Okay.
`MR. BORDER: After the trusted third- party
`device receives this request, it uses information in the
`request, including the domain name of terminating device
`26, to look up the public IP address, the second network
`device, and the terminating device. This information is
`used to subsequently establish a tunnel.
`Now, I've included an excerpt from RFC 2401.
`And this is at page 25 of RFC 2401. RFC 2401 describes
`the IP sect protocol. It describes a method of -- the
`protocol describes a method of automatically encrypting
`traffic sent over a public network.
`In Case 3 of RFC 2401 shows a network
`configuration that we relied on in our petition that is very
`similar to the architecture of Beser. It describes two end
`devices, H1 and H2. And it describes an association with
`each one of those end devices, SG1 and SG2. And what
`RFC 2401 tells us is it describes a way to create an
`end-to-end encryption between H1 and H2, the two end
`devices.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`7
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`And what we explained in our petition is that a
`person of ordinary skill would look at this figure and
`would recognize the parallel network structure between
`Case Number 3 and RFC 2401 and the Beser architecture.
`And that's in our petition at page 28. And Dr.
`Tamassia also discussed this in his declaration, Exhibit
`1005, at 396 to 397.
`Let's first talk about whether combining Beser
`and RFC 2401 would have been obvious to one of ordinary
`skill in the art. As we explained in our petitions, the
`answer is yes. Slide 6 please.
`Beser, at column 1, lines 54 through 58, tells
`us that ordinarily a sender can encrypt information inside
`an IP packet using this IP sect protocol. But Beser also
`notes that doing that does not hide the identities of the
`communicating parties.
`And in the bottom passage, which is at column
`2, lines 1 through 5, Beser goes on to note that this lack
`of anonymity creates a security problem even when
`encryption is used to encrypt that information. Slide 7,
`please.
`
`So Beser, what Beser discloses is a method --
`is that this tunneling method that helps to solve this
`problem.
`
`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
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`JUDGE EASTHOM: So, Counsel, say if Beser
`does hide the addresses using this anonymity tunnel
`technique, are you saying that a hacker could not then
`determine what those private addresses are if they were
`given enough information in terms of whether or not if it's
`encrypted?
`MR. BORDER: Well, what I think Beser is
`telling us is because it does use private IP addresses,
`those are not relevant. Those are not IP addresses that a
`-- for example, an outside hacker could use to find out
`what those devices are. Those are IP addresses that are
`assigned by the first and second network devices in Beser.
`So they themselves mean nothing to an outside hacker.
`And because they are able to use these private
`IP address -- excuse me -- because they are able to use
`these private IP addresses, they are able to complement
`encryption by providing this anonymity that encryption
`itself won't provide. And Dr. Tamassia said the same
`thing. And this is in Exhibit 1005 at paragraph 398 to
`400.
`
`Now, Patent Owner contends that Beser
`actually teaches away from using encryption, but we don't
`agree. As we saw earlier, Beser teaches that it is a
`complement to encryption, not a replacement for it. Go to
`slide 11.
`
`
`
`9
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`JUDGE BISK: I have a question. Is there any
`difference between the arguments on this particular issue
`in this case than there were in the --
`JUDGE EASTHOM: 237?
`JUDGE BISK: -- 237 case?
`MR. BORDER: Well, Your Honor, I was just
`about to address that.
`JUDGE BISK: Okay. MR. BORDER: In the
`IPR2014- 237 --
`JUDGE BISK: What slide is this?
`MR. BORDER: Your Honor, excuse me. This
`is slide 11.
`JUDGE BISK: Thank you.
`MR. BORDER: In the IPR you just referred
`to, which is 2014- 00237 at 41, the Board considered this
`exact same issue. And Patent Owner has offered no new
`evidence or no new arguments in these proceedings such
`that there is no reason for the panel to depart from that
`previous determination.
`JUDGE BISK: Can I ask kind of some
`technical questions about the similarities here. So the
`patent at issue in 237, is the specification for that patent
`exactly the same as the two patents in this case?
`MR. BORDER: It's not exactly the same, but
`it is virtually the same. The patent that we are dealing
`
`
`
`10
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`with here, I believe, is a child of the patent, but -- and the
`relevant disclosure that we are sort of analyzing is
`virtually identical.
`JUDGE BISK: Okay.
`JUDGE EASTHOM: What about the
`determining step? I mean, given that you are combining
`2401 with Beser to reach encryption, how does the Beser
`system determine that these end devices are available for
`the encrypted part of the Claim 1? It says -- hold on one
`second -- determining whether the request to look up the
`IP address corresponds to a device that accepts an
`encrypted channel connection with the client device.
`So I guess I'm wondering -- I can see how
`Beser might determine what we found in the 237 case that
`these things are for secure communication because they
`have a private IP address, if they are listed. That's kind
`of what we read, I think, in the 237 case.
`But how do you go to the next step and say,
`okay, they also show that this secure device is encrypted,
`if you are using Beser with 240 1 to sort of get the
`encryption part of it?
`MR. BORDER: So, just to be clear, Your
`Honor, are you asking the determination step in Beser,
`how does it determine whether or not one of these end
`
`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
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`devices is one that accepts an encrypted channel
`connection?
`JUDGE EASTHOM: Correct.
`MR. BORDER: Well, Your Honor, what Beser
`tell us is that the third-party trusted network device is a
`modified DNS server. And it contains a database. And
`this database includes the IP addresses. For example, the
`second network device and devices that correspond --
`JUDGE EASTHOM: I understand that. It
`looks up a private address and figures out whether this
`thing can be connected in a secure method. And using
`this anonymity technique, but how does that get you to the
`encryption part of that?
`MR. BORDER: Well, the encryption part is
`supplied by RFC 2401.
`JUDGE EASTHOM: So how does Beser know
`that this device is ready for encryption, Beser’s system?
`Are you combining the two somehow? I'm trying to figure
`out how you are reaching that step and where you address
`that.
`
`MR. BORDER: Well, Your Honor, I believe
`what we explained in our petition, and this is -- what we
`explained in our petition are that the end devices are --
`the devices that are included in this database, the database
`discussed at column 11, lines 20 through 58, and this is a
`
`
`
`12
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`petition at 33; these are devices that support the
`encryption.
`And by virtue of being in this directory
`service, this database, that is a determination that it is
`available for the secure communication service.
`JUDGE EASTHOM: So what you are saying
`then is that all the secure devices that are listed there that
`are able to provide anonymity, those all are -- those all
`have encryption in your combination. Is that --
`MR. BORDER: That's correct, Your Honor.
`They all support end-to-end -- in the combination, these
`are devices that support an end-to-end encryption.
`JUDGE EASTHOM: Okay.
`MR. BORDER: Let's go back to slide 14,
`please. You have to focus on the second step for a
`second. This is whether Beser and RFC 2401 show a
`request to look up an IP address.
`If we can quickly go to slide 4, please. And
`the request we are talking about here is the request from
`the originating device 24 that includes the domain name of
`device 26. This is request 112. Please go to slide 15.
`The first step is intercepting from the client
`device a request to look up an IP address corresponding to
`a domain name associated with the target device. Let's go
`to slide 17.
`
`
`
`13
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`We showed in the petition that Beser explains
`that two IP addresses are actually looked up in response to
`this request, the public IP address for the second network
`device, and the private IP address for the terminating
`device.
`
`We also showed in our '812 proceeding that
`this satisfies the '009 patent as well, which uses a similar
`phrase, DNS request to look up the network address.
`That's based on the agreement between the parties that the
`construction of a DNS request is a request for resource
`corresponding to a domain name.
`In response, Patent Owner argues that Beser
`does not look up an IP addresses, but that's not true. Let's
`go to slide 21 please. This is the slide that we looked at
`before.
`
`And, again, it explains to us that what the
`third- party network device does is it consults a database
`as a typical domain name server would do, and associates
`the IP address of the second network device with the
`unique identifier, the domain name it receives in the
`request.
`
`So apart -- so in fact the third- party network
`device does perform a look up. Dr. Tamassia agreed, if
`you can go to slide 22, this is at column -- Exhibit 1005,
`paragraph 310. He agreed that this disclosure in Beser
`
`
`
`14
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`supports our evidence that Beser, in fact, does disclose a
`look- up. And, in any event, the claims do not specify that
`a look-up is performed, nor discuss the mechanics of how
`it is performed.
`Let's very quickly go to slide 24. Now, Patent
`Owner makes --
`JUDGE BISK: I kind of -- I think I
`understood their argument a little differently, which is not
`that nobody doesn't DNS request, just that it's not the
`originating -- the originating requestor, or they are
`initiating a tunnel, not requesting a DNS.
`MR. BORDER: Well, Your Honor, the
`construction in the '812 proceeding, the agreed
`construction agreed to by both parties was simply a
`request for a resource corresponding to a domain name.
`JUDGE BISK: Right. But I think their
`argument is that it's the wrong entity doing the looking
`up, if I'm not mistaken.
`MR. BORDER: I understand your question,
`Your Honor. That's incorrect. If we can go to slide -- and
`let me show you how or why. Let's go to 25, please, slide
`25.
`
`It's actually not true. It's actually the
`preferred embodiment of Beser that explains that the
`negotiation that takes place is performed by the third
`
`
`
`15
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`party, the trusted third-party network device. And this is
`in Beser at column 9, lines 29 through 30.
`And what the trusted third- party network
`device says is not only does it look up the IP address of
`the second network device, it also through this negotiation
`method between the first and second network devices also
`determines the private IP address of the terminating
`device 28. So it actually looks up two.
`JUDGE BISK: Can we look at one of the
`claims for a minute, maybe Claim 1 of the '009 patent is
`what I have right in front of me.
`MR. BORDER: Of the '009 patent?
`JUDGE BISK: Yeah, if you have it handy. So
`I'm trying to figure out from this claim language what is it
`that sends the DNS request?
`MR. BORDER: What is it in Beser, Your
`
`Honor?
`
`JUDGE BISK: Or what is it in the claim, first,
`and then what is it in Beser?
`MR. BORDER: Well, Your Honor, this is -- in
`this claim it's simply a network device that would ascend
`this domain name service request. And so in Beser what
`we've pointed to was the originating device 26. If you can
`go to slide 24, please.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`16
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`JUDGE BISK: Right. And so if the network
`device is the originating device, then you seem to kind of
`change in the middle of there and say now it's actually the
`third- party trusted device that actually sends the DNS
`request, right?
`MR. BORDER: Oh, I'm sorry. Maybe I
`misspoke. The device 24 is the device that generates the
`request to look up an IP address. It is intercepted by
`device 14 and device 30. The look- up is performed by
`device 30.
`
`JUDGE BISK: Okay. And so tell me again
`how the originating device 14, is it? I am sorry, 24.
`MR. BORDER: 24, Your Honor.
`JUDGE BISK: How is it requesting a DNS
`
`look- up?
`
` MR. BORDER: Well, again, the agreed
`construction of a DNS look- up -- do you have the Patent
`Owner response at 3?
`MR. BROUGHAN: Let me get that.
`MR. BORDER: The requested look-up -- this
`is Patent Owner's response in the '812 proceeding. The
`DNS request was agreed to be simply a request for a
`resource corresponding to a domain name. So as you can
`see from the agreed constructions, there is no requirement
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`17
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`that they follow any sort of protocol, any DNS protocol,
`for example.
`Your Honor, does that address your question?
`JUDGE BISK: So by initiating a tunnel, you
`say initiating a tunnel qualifies?
`MR. BORDER: Yes. Yes, Your Honor. This
`is very broad language. It's simply a request for a
`resource. The resource that is returned is an IP address.
`And there is no dispute that that is a resource in the
`claims.
`
`Let's go to slide 27, please. Actually, let's go
`slide 26. Just to conclude on that issue, this similar issue
`came up in IPR2014-00237. There the Board also found
`that the request in Beser was a request to look up an IP
`address.
`
`This was in the final written decision at page
`24. And again the Patent Owner has offered no reason for
`the Board to depart from that previous, incorrect
`determination.
`Slide 27, please. Next, let's talk about
`whether the request in Beser is intercepted. Slide 4,
`please. Again we are -- JUDGE BISK: Can I ask a
`question?
`
`MR. BORDER: Yes, Your Honor.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`18
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`JUDGE BISK: I'm sorry. There's a lot of
`discussion on claim construction in the brief that seems
`like in the end didn't really apply to these cases. But one
`thing that nobody actually touched on is the word
`"intercepting." But that seems to be actually at issue here
`is the construction of the term "intercepting."
`MR. BORDER: Yes, Your Honor. And I
`notice in the Institution Decision, the Board did not
`believe that construction was necessary. However, in that
`previous decision, the Board did arrive at a construction.
`If you can go to slide --
`JUDGE BISK: That's the 237?
`MR. BORDER: This is the 237 case, Your
`Honor. And in that proceeding what the Board determined
`was that receiving an interception meant receiving a
`request pertaining to a first entity at another entity. And
`so if you can go to slide 4.
`JUDGE BISK: And what does "pertaining to"
`
`mean?
`
`MR. BORDER: Well --
`JUDGE BISK: I think in this case that's where
`the argument is. It's a little deeper.
`MR. BORDER: Well, I think we agree with I
`think some of the basic tenets of this construction. I think
`
`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
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`Patent Owner also includes this concept of performing an
`additional step after that interception.
`JUDGE BISK: Right.
`MR. BORDER: But I note -- let's go to slide
`33. And this is the only example in the patent that
`discusses this concept of intercepting a request. And
`there's two things to take away from this passage. And
`it's, first, all requests from the client are sent to one
`device, DNS proxy 2610.
`And, second, there is no indication that this
`interception has any special meaning. So in the disclosed
`embodiment, a single -- the request pertains to, for
`example, the destination, the terminating device in Beser.
`However, it is received or intercepted, in the language of
`the claims, by another device.
`And that is the concept that I believe the
`Board was trying to capture with that construction. And I
`should note -- if you can go to slide 34, at his deposition I
`asked Patent Owner's expert what his understanding of the
`term "intercepting" was. And he explained to us that he
`had no opinion of what the term requires.
`So we agree with the Board's previous
`construction, receiving a request pertaining to a first
`entity and another entity. And applies -- and as applied to
`Beser, if we can go to slide 35, again the Patent Owner
`
`
`
`20
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`has given the Board no reason to depart from this previous
`determination where it found an interception both at
`device 14 and device 30.
`JUDGE EASTHOM: Did the Patent Owner
`challenge that claim construction in their brief in the
`Federal Circuit for the 237 case, do you know, or --
`MR. BORDER: Your Honor, I think you've --
`I think you have asked me a question that I just don't have
`at my command right now.
`JUDGE EASTHOM: That's all right. I'm just
`
`curious.
`
`MR. BORDER: I apologize, Your Honor. I
`don't believe this was at issue in the Federal Circuit, but I
`don't --
`
`JUDGE EASTHOM: Well, whatever.
`MR. BORDER: Okay. I believe they have
`challenged it to the extent that it requires some additional
`evaluation steps.
`JUDGE EASTHOM: Okay.
`MR. BORDER: But I honestly don't have that
`fresh, Your Honor.
`JUDGE EASTHOM: That's okay.
`MR. BORDER: Sorry.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`21
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`JUDGE ANDERSON: So I want to ask you
`about encryption. Beser doesn't really teach encryption;
`isn't that right?
`MR. BORDER: Your Honor, what it explains
`is that encryption alone is not a satisfactory way to secure
`a communication. So it teaches a complementary method
`for hiding the ends of those -- that encrypted channel so
`that hackers, for example, cannot find out who's doing the
`communication.
`JUDGE ANDERSON: So it doesn't teach
`encryption?
`MR. BORDER: It doesn't teach -- well, it
`does say that encryption is typically used. It does
`recognize that there are some certain circumstances, such
`as high media, high bandwidth media applications where
`encryption might not be used, but it does state that
`typically encryption is used in communicating packets in
`its system.
`And that description is -- if you can go to
`slide 6. And here it's discussing some of the benefits of
`encryption and some of the drawbacks. It says the sender
`may encrypt the information inside its IP packets before
`transmission with this IP sect protocol. That's the RFC
`2401 we've been discussing.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`22
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`What Beser states is that it's simply a
`complement, an additional element of security that can be
`added to what is otherwise an encrypted communication.
`Why don't we go to slide 36. The final issue
`of contention relates to the '009 patent only. Let's go to
`slide 37. The claim specifies receiving certain
`information, including an indication that the second
`network device is available for the secure communications
`service and the requested network address of the second
`network device.
`Now if we can go to slide 38, please. Patent
`Owner asserts that Petitioner is essentially
`double-counting, because we are pointing at the private IP
`address of the terminating end device to satisfy both claim
`elements. That's not true.
`If we can go to the next slide, please, slide 39.
`In the petition at page 41, what we explained was the
`indication is met by the receipt of both the private IP
`address of the originating device and the receipt of the
`private IP address of the terminating device. It is the
`receipt of both of these private IP addresses that serves as
`the indication of the claims.
`Let's go to slide 40. I have used --
`JUDGE BISK: You are about at 25 minutes
`
`just now.
`
`
`
`23
`
`
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`MR. BORDER: Thank you, Your Honor. I'm
`going to fast forward through the next steps. I'm going
`the shift gears to the '811 proceeding, which deals with
`Aventail. I'm going to focus on one issue. And then I'm
`going to get to my conclusion.
`Let's go to slide 41. Quick overview of the
`architecture of Aventail. This is at Aventail, page 72. It
`describes a way of establishing a BPN between mobile
`users and private users on a network, together with an
`Aventail client, which is called Aventail Connect. It's
`software running on mobile users, and the Aventail BPN
`server, which is also called the Aventail Extranet Server.
`And what Aventail 10 explains to us is that at
`a high level, what happens is that Aventail Connect, the
`software on the mobile user, receives a connection
`request, and then it determines whether or not it needs to
`be redirected and encrypted.
`Let's go to slide 45. Now I have highlighted
`here both the first and second step of Claim 1 of the '705
`patent. I've highlighted it because the request that is
`discussed in Claim 1, or the first element of Claim 1, is
`relevant to the request that the determination is made on
`in the second step of the claim.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`24
`
`
`
`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
`
`Case IPR2015-00810 (Patent 8,868,705 B2)
`Case IPR2015-00811 (Patent 8,868,705 B2)
`Case IPR2015-00812 (Patent 8,850,009 B2)
`
`
`We explain in our petition that Aventail
`Connect, the Aventail Connect client -- let's go to slide
`42, please.
`We explain in our petition that when a user
`issues a connection request in a web browser, for example,
`that matches a secure destination on the private network,
`the application does a DNS look-up to convert the host
`name to an IP address.
`Aventail Connect will intercept that, evaluate
`it against a redirection rule, and then return this false
`DNS entry called the HOSTENT. These are the first --
`this is the first step of Aventail. It's the step that we
`relied on to show that Aventail satisfies the first and
`second steps of Claim 1 in the '705.
`If you go to slide 43, Patent Owner's response
`is a red-herring. They point you to what happens after
`Aventail Connect has intercepte