throbber
trials@uspto.gov
`
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket