`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE, INC.,
`Petitioner.
`
`v.
`
`VIRNETX, INC.,
`Patent Owner.
`____________
`
`Case IPR2017-00337
` (Patent 9,038,163 B2)
`____________
`
`Record of Oral Hearing
`Held: February 27, 2018
`____________
`
`
`
`
`
`Before KARL D. EASTHOM, JENNIFER S. BISK, and KEVIN C.
`TROCK, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`
`JOSEPH A. LOY, ESQUIRE
`Kirkland & Ellis, LLP
`601 Lexington Avenue
`New York, New York 10022
`(212) 446-4980
`
`DANIEL ZEILBERGER, ESQUIRE
`NAVEEN MODI, ESQUIRE
`Paul Hastings, LLP
`875 15th Street Northwest
`Washington, D.C. 20005
` (202) 551-1993
`
`
`
`
`The above-entitled matter came on for hearing on Tuesday, February
`
`27, 2018, commencing at 1:00 p.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`2
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`
`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
`26
`
`P R O C E E D I N G S
`- - - - -
`JUDGE EASTHOM: Welcome everybody. This is IPR2017-00337,
`U.S. Patent Number 9,038,163. We have Judge Trock over in California.
`Judge Bisk, to my right, and I'm Judge Easthom. Why don't we have Patent
`Owner -- and this is Apple, Inc. versus Virnetx, Inc. So, why don't we just
`have Petitioner introduce yourself for the record, please.
`MR. KISHHAN: Thank you, Your Honor, Jeff Kushan from Sidley,
`Austin. With me, Joe Loy from Kirkland, who will be doing the argument,
`and Scott Border from Sidley.
`JUDGE EASTHOM: Could you repeat that, please? I was rustling
`with papers, my mistake.
`MR. KISHHAN: Sure. Jeff Kushan from Sidley, and lead counsel
`Joseph Loy from Kirkland and Ellis, who will be doing the argument, and
`Scott Border also from Sidley.
`JUDGE EASTHOM: Thank you.
`JUDGE BISK: Is that microphone on?
`MR. KUSHAN: Can you hear?
`JUDGE EASTHOM: Can you hear, Judge Trock?
`JUDGE TROCK: I can hear counsel, I can hear you Judge Easthom.
`JUDGE EASTHOM: Okay. Thank you. For Virnetx?
`MR. ZEILBERGER: Good afternoon, Your Honor, Daniel Zeilberger
`with Virnetx and I'm joined by
`Naveen Modi.
`JUDGE EASTHOM: Welcome. We have 30 minutes per side.
`Petitioner, you have the burden, you'll go first. Patent Owner can respond
`
`
`
`3
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`but if Patent Owner wants to also -- we have a Motion to Exclude, they can
`bring that up on their half and then whatever rebuttal you want to say we'll
`go forward with that. We'll reserve time if you ask for it.
`MR. LOY: Thank you, Your Honor. May I approach with copies of
`the demonstratives?
`JUDGE EASTHOM: Sure, thank you.
`MR. LOY: Good afternoon, Your Honors. I would like to reserve 10
`minutes for my time for rebuttal, if I may. Slide 2, we're here today to
`discuss whether certain claims of the '163 patent are obvious in view of three
`references; Beser, RFC 2401, and RFC 2543. I plan to focus my discussion
`today on the issues raised by Patent Owner in its response, and I'm happy to
`answer any questions that the Board has as I proceed. Claim 4 -- slide 4,
`rather. Claim 1 of the '163 patent is illustrative of the challenged claims.
`It includes a method for connecting two network devices over a
`communication network comprising several steps. There's a receiving step,
`receiving a request to lookup a network address, including -- they're based
`on an identifier which can be either a domain name, a VOIP phone number,
`or an e-mail address. The evaluating step, that requests to determine if the
`identifier is registered with a name service, and that name service can be a
`domain name, for example -- domain name service, rather, for example.
`And then a determining step, whether the second network device is
`available to communicate through a direct encrypted communication link.
`Now, the technologies described in the '163 patent including DNS servers,
`domain names, and VPNs were all well-known in the prior art as of the time
`of the effective filing date of the '163 patent, which is February 15th of
`2000. Slide 5, please, the prior art references in the petition include the two
`
`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
`26
`
`
`
`4
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`references that are illustrated here on slide 5, the Beser reference depicted as
`figure 1 at the upper left-hand corner, and figure 6 on the right, as well as
`RFC 2401 which is the IPsec protocol.
`Now, the basic idea behind Beser is that there's a creation of an IP
`tunnel. There's negotiation of IP addresses between a first network device
`and a trusted third-party device, which enables to end user devices an
`originating and a terminating device to communication securely using a
`tunnel, so that each side knows the private IP address of the other. Now, we
`combine in this petition the IPsec protocol, which is an IEP publication that
`discloses end-to-end encryption, it allows, when combined with Beser, for
`two end user devices to communicate through an end-to-end encrypted
`tunnel.
`Slide 6, finally, the third reference at issue in this is a combination
`with RFC 2543, which is the IPsec protocol -- sorry, the SIP protocol. The
`SIP protocol has another layer which, again, is the same architecture of
`Beser. You have an originating device that sends an invite message through
`to a terminating device. That's a process through a location service which
`looks up the identifier of the originating device or the terminating device,
`and then sends on an invite message through to the terminating device. In
`which case a VOIP phone, for instance, the phone rings and if the end user
`determines that they would like to accept the call there's an opinion to
`accept, in which case a message is then -- an accept message, 200, is then
`returned through to the originating device and an acknowledgement message
`goes back to allow the two devices to negotiate an IP tunnel and, again, have
`a secure and anonymous communication link.
`
`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
`
`
`
`5
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`
`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
`26
`
`Now, if you switch to slide 9, please. The '163 patent is one of a
`number of patents that have been -- part of a family of patents that have been
`evaluated by this Board. A number of the proceedings here on slide 9 are
`Federal Circuit decisions that have evaluated and rendered unpatentable
`related claims in the family. These have all been affirmed by the Federal
`Circuit and the time within which to file a sur petition has expired. Slide 10,
`please, additionally, there is another group of IPRs which the Board has
`determined, and here we have through the '810 proceeding down through the
`'870 proceeding.
`That group of IPRs was not consulted before the Federal Circuit and is
`prepared for oral argument on March 5, this coming Monday. There is also
`the '321 proceeding, which was fully briefed I believe at this point, as of the
`beginning of February and it's still waiting a determination for an oral
`argument. Now, just briefly the consolidated appeals here, that will be
`argued on Monday next week, the main issue that overlaps with those and
`I'll -- it's important that they all involve Beser as well as the IPsec protocol,
`RFC 2401.
`The main issue that Patent Owner is brining up on that appeal is that
`RFC 2401 is not a printed publication under 102B and, therefore, the Board
`should not have relied on it. As to the combination or any of issues with the
`technical functionality or description within 2401, that is not at issue in this
`case. So, let's go to slide 11 for a moment. Just briefly, the issues I intend to
`discuss substantively today, unless the Board has further questions, are
`whether Beser discloses a request to lookup a network address.
`Second, whether a person having ordinary skill would combine the
`prior art at issue in this proceeding. Third, whether Beser teaches away from
`
`
`
`6
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`using encryption. And, fourth, whether the prior art disclosed the
`authorization step of the '163 patent. The last issue here is the Patent
`Owner's Motion to Exclude as well as their contention that the two RFCs are
`not prior art. Because that issue has been fully briefed and decided by this
`court, even as recently as last week, unless you have questions on it I don't
`intend to argue.
`So, let's turn to the argument that Beser does not disclose a request to
`lookup a network address, that's slide 15. Now, this argument, in particular,
`has already been decided by this Board. If we look to the '273 decision, or
`the final written decision in the 237 IPR, you'll see that the Board concluded
`that Beser's tunneling request, which includes a domain name, is indeed a
`request to lookup an IP address. Now, Patent Owner does not present any
`new evidence or any new argument, so for the same reasons the Board had
`previously held we submit the Board should reach the same conclusion here.
`As I briefly mentioned earlier, on the appeal that's currently pending before
`the Federal Circuit this issue was not raised.
`JUDGE TROCK: Excuse me for a second, counsel, this IPR you're
`referring to, 237?
`MR. LOY: Yes.
`JUDGE TROCK: Is that the exact same claim language?
`MR. LOY: There is some subtle differences in the claim language but
`the concept is the same, Your Honor. So, the issue of whether or not a
`domain name is looked up by a DNS, domain name server, was at issue in
`that case and so the same -- the question you have to ask yourself here is
`principally addressed in this IPR.
`
`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
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`
`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
`26
`
`JUDGE TROCK: Well, let's take a look at the claim we have before
`us, which is Claim 1. So, it appears that the Patent Owner is contesting the
`disclosure or teaching by your combination of the request to lookup a
`network address of the second network device based on the identifier
`associating with the second network device and evaluating the request to
`determine whether the identifier is registered with a name service. Is that
`your understanding of what they're disputing?
`MR. LOY: That is particularly what they're disputing, that's correct.
`JUDGE TROCK: So, is that the claim language that was decided in
`
`'237?
`
`MR. LOY: It's not exactly identical but the concept, again, is --
`JUDGE TROCK: What's different, because if you want me to go look
`at what resolved in '237 and apply that here I take it the claim language
`ought to be very closely related to each other.
`MR. LOY: Indeed, they are.
`JUDGE TROCK: Because if not, that's a problem.
`MR. LOY: Indeed, the claim language is nearly identical. The
`concept here about a request to lookup a network address, and in this
`instance the Patent Owner does not dispute that the network address can be
`an IP address. And the conclusion reached by the Board in the '237 decision
`was that Beser does disclosure a lookup of an IP address.
`JUDGE TROCK: Right, but there's more than just the lookup here in
`this claim. They're disputing more than just the lookup. They're -- lookup a
`network address of the second network device based on an identifier
`associated with the second network device, and then evaluate the request to
`determine whether the identifier is registered with a name service.
`
`
`
`8
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`
`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
`26
`
`MR. LOY: Correct. So, why don't we turn back to slide 5.
`JUDGE TROCK: So, maybe you can show me where that is being
`taught in your references.
`MR. LOY: Sure. On slide 5, for instance, if you look at figure 6,
`Your Honor, Beser shows that an originating device, 24, initiates an IP
`tunnel with terminating device, 26. It does that by sending out a tunnel
`request that is -- it contains 26's unique identifier, so that is an IP address.
`JUDGE TROCK: So, are you arguing that that tunnel request is a
`lookup request?
`MR. LOY: Indeed, and additionally there's another lookup request
`and that lookup request is
`when --
`JUDGE TROCK: Well, which one are you relying on here for the
`lookup?
`MR. LOY: Well, we -- both of them will work, so you'll see multiple
`lookups --
`JUDGE TROCK: So, either?
`MR. LOY: Yes.
`JUDGE TROCK: Your position is either?
`MR. LOY: Indeed.
`JUDGE TROCK: All right, so let's start with the first one then,
`tunneling request.
`MR. LOY: Okay.
`JUDGE TROCK: How is this tunneling request a lookup request?
`MR. LOY: The lookup request -- sorry, I'm hearing feedback. The
`originating device on 24 sends the first request to initiate a communication
`
`
`
`9
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`link with the telephone device at 26. So, the first request goes to the first
`network device, 14. The first network device, 14, then will determine -- so
`that looks up an IP address of the trusted third-party network device then --
`JUDGE TROCK: Request 112 does that?
`MR. LOY: That's right, and then first network device, 14, then
`communicates with the trusted third-party network device which then looks
`up, again, a private IP address so that it can determine whether it's going to
`associate the, 26, which is the terminating telephone device with the
`originating telephone device. So, there's another lookup that occurs there.
`JUDGE TROCK: In either one of those lookups it's your position that
`that's a lookup request as it's recites in Claim 1, is that right?
`MR. LOY: Correct. So, the next issue if we would turn to slide 18, is
`whether or not one of ordinary skill in the art would combine Beser, 2401,
`and 2543. Now, Patent Owner argues that one of ordinary skill in the art
`would not combine Beser and 2401 urging that -- because Beser has a
`statement about potential jitters or a lost packets that may occur when
`encrypting data that one would not combine these two references. Notably,
`Patent Owner does not argue, other than impeding in a deposition brief, that
`a person having ordinary skill in the art would not combine the SIP protocol
`with Beser.
`Let's turn to slide 19, again, in the '237 IPR final written decision the
`Board held that the record shows that artisans of ordinary skill in the art
`would have recognized that Beser and the IP SIP protocol would be
`combinable and that is precisely because the Beser reference, it discloses
`encryption in a way in which to communicate security over the Internet, and
`using public networks like those disclosed in the '163 patent. Additionally,
`
`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
`26
`
`
`
`10
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`the Beser reference describes some of the computational issues that you may
`encounter if you are encrypting end-to-end and the solution to that is also
`included that you just need additional computing power.
`There's no teaching away as the Board has found. The same is true
`for the combination of RFC 2543 with Beser. As Apple's expert, Dr.
`Tamassia set forth in his declaration at Exhibit 1003, paragraphs 252-264,
`Beser discloses that a system is compatible with a VOIP H.323 protocol as
`well as other VOIP protocols and it isn't contested that IETF, RFC 2543 is
`indeed one of those protocols. Let's turn now for a moment to slide 21.
`Patent Owner also argues that similar argument that the audio and video
`end-to-end encryption claim claimed in dependant claims 2 through 4, and
`13 would suffer from the same issue that Beser discloses or allegedly
`describes as not using end-to-end encryption.
`Indeed, if we look to slide 24, again, this Board has conclude in the
`'868 proceeding that not only does Beser teach encryption but one of
`ordinary skill in the art would be encouraged to combine Beser and its
`encrypted tunnel with the IP SIP protocol 2401. Unless the Board has
`questions about that combination Petitioner intends to stand on its briefs and
`prior arguments on that issue.
`JUDGE EASTHOM: I don't have any questions.
`JUDGE TROCK: I don't have any.
`MR. LOY: If we look to slide 26 for a moment. So, the '163 patent
`also has two dependent claims that include determining whether the first
`network device is authorized to communicate with the second network
`device through the direct encrypted communication link. Jump to slide 28,
`Patent Owner's argument here is that the mere disclosure of a request being
`
`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
`26
`
`
`
`11
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`authenticated isn't sufficient to disclose the claimed determination. Now, in
`the '237 proceeding, if we could flip to slide 29, please, Dr. Monrose, who is
`Patent Owner's expert testified that the related '697 patent shows several
`ways of determining authorization including whether or not they can accept
`the site being requested.
`This is the same as determining whether or not the first network
`device is authorized to communicate, asking whether or not it's an access,
`and if there's no authorization to access then there is a determination that it
`can not communicate. We'll go to slide 30 for a moment. Moreover, in the
`IPR '237 proceedings the Board found that authenticating or encrypting
`packets to hide the unique identifier, Beser's system may grant
`communication access to the sending device, 24. And that, again, is
`precisely the first device authorizing to communicate with the second
`network device. Because Patent Owner offers no new evidence or argument
`to justify the Board deviating from this prior conclusion we would urge the
`Board to reach a similar conclusion. And with that I would, unless there are
`further questions, I will turn it over to Patent Owner.
`JUDGE EASTHOM: I have no further questions. I think you have
`about 14 minutes left.
`MR. LOY: Thank you.
`JUDGE EASTHOM: More like 12, I'm sorry, I miscalculated.
`MR. ZEILBERGER: Good afternoon, and may it please the Board.
`Just briefly I'd like to clarify two points on responding to what Apple's
`counsel said. On slide 9 of Apple's demonstratives we have kind of a table
`of Federal Circuit decisions. I just wanted to make sure that the Board is
`aware that in none of the decisions that the Federal Circuit issued none of
`
`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
`26
`
`
`
`12
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`them actually relied on Beser in all instances. When they ruled on the
`patentability of those patents there were a lot of different prior art references
`and not Beser.
`Also, responding to the issue that came up on whether there's any
`differences in Claim 1 at issue here and Claim 1 at issue in IPR2014-00237.
`There are several differences, but one I just want to make sure the Board is
`aware of, there's no evaluating limitation in the patent at issue there whereas
`there is here. Having said that I'd actually like to focus my time today on
`two of the dependent claims, Claims 21 and 42, which recite that there's a
`determination that the first network device is authorized to communicate
`with the second network device.
`Apple has not demonstrated that these two claims are obvious in view
`of their proposed combination and these claims should be found patentable.
`If you look at Apple's petition their arguments on page 64 through 65 and
`you will see that they really actually only cite to a single sentence in Beser to
`try to address these two claims. That passage provides, quote, IP packets,
`58, may request encryption and authentication and that's essentially all it
`says. And if you look at the whole paragraph of that sentence, again, it
`doesn't mention authentication -- excuse me, it doesn't mention
`authorization, it doesn't mention the originating end device, 24, which is
`what Apple now says is the first network device in the claim.
`It's simply a filing on those features, and what they've raised is
`essentially non sequitur. They point to a random passage in Beser that
`mentions encryption and authentication, it doesn't talk about authorization at
`all. We've raised that point about Beser's silence in pages 20 to 21 in our
`Patent Owner's response. And Apple raised a number of different responses
`
`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
`26
`
`
`
`13
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`in their reply and I'd like to go through really each of those in turn. Because
`I think if we break down what they're actually saying you'll see that while
`they cite to a lot of different pieces of evidence actually the underlining
`evidence doesn't support their assertion.
`JUDGE EASTHOM: Counsel, maybe just to give us some
`background could you just clarify what you mean by authorization? How
`that's supported in your patent or maybe that's --
`MR. ZEILBERGER: Sure, Your Honor, of course. If you were to
`look under the '163 patent there's example disclosures at column 40, lines 33
`to 37 where it says, quote, if access to a secured site has been requested DNS
`proxy 2610 determines whether the user has sufficient security privileges to
`access the cite. Another example is column 41, lines 14 through 27 where it
`says, quote, if access to a secure host was requested then in step 2704 a
`further check is made to determine whether the user is authorized to connect
`to the secure host and then there's a second check (inaudible) that give the
`examples on what this authorization would look like.
`JUDGE EASTHOM: Thank you.
`MR. ZEILBERGER: So, Apple's reply to our argument really starts
`on page 17 and I'll really just step through each sentence that they argue.
`First, they argue that, quote, Beser's trusted third-party network device must
`be able to encrypt and authenticate the received request to determine
`whether to grant the tunneling request. And, again, that doesn't say anything
`about authorization or the authorization, in particular, of the originating end
`device, 24. Then they go on to argue, quote, in further processing the
`request the unique identifier is compared with a database that includes
`
`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
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`authorized users or devices, and then they cite to Beser at column 11, lines
`48 to 52.
`At the outset it's not clear whether they're relying on this for these
`claims. They certainly didn't rely on this passage of Beser in the petition,
`but even if they had this wouldn't be sufficient because this, again, is not
`talking about -- for starters, that they have in their argument that it's talking
`about authorized users. Beser actually doesn't mention authorized users, but
`even if it did that passage is talking about the second network device, 16,
`and the terminating end device, 26, not the originating end device, 24. And,
`in fact Dr. Tamassia makes that clear in his declaration at paragraph 178,
`where he refers -- when discussing the exact same passage second network
`device, 16, and terminating end device, 26.
`And even Apple's petition, when discussing a different limitation, the
`evaluating limitation of Claim 1, they also when discussing this passage
`related to the second network device, 16, and the terminating end device, 26.
`Then, in the same paragraph on the next page Apple argues, quote, that in a
`prior decision the Board previously found Beser's system effectively may
`grant communication access by authenticating or encrypting packets to hide
`the unique identifier on the public network, end quote. At the outset I think
`the key problem here is that completely different claim language was being
`analyzed by the Board in the '237 proceeding.
`In that proceeding the claim read, quote, determining in response to
`the request whether the second network device is available for a secure
`communication service. Here, again, the claim says determining that the
`first network device is authorized to communication with the second
`network device. The Board did not find in the '237 proceeding that there's
`
`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
`26
`
`
`
`15
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`any disclosure relating to the authorization of the claimed first network
`device. Then on the next paragraph on the same page Apple argues that,
`quote, Patent Owner never explains why Beser's disclosure is sufficient. It
`simple asserts that Beser and Dr. Tasassia's declaration are silent regarding
`this claim step, but that's textbook nonobviousness or non-anticipation.
`There's no disclosure of the silence, that means they don't have any
`evidence. It was Apple's burden to show that Beser, which is what they rely
`on, satisfies these claims and they did not do that. And then Apple goes on,
`quote, the '163 patent explains that authorization can be determined in
`numerous ways including by checking a list communicating with a
`gatekeeper or transmitting a request message back to the user's computer.
`At the outset Apple doesn't explain how this relates at all to Beser's
`disclosure, or the claims, or whether they're raising a new argument and just
`kind of inserted it.
`But I want to make sure the Board is aware that Apple is kind of
`omitting critical description in the '163 patent about these things. So, for
`example, they point to checking a list but, in fact, the '163 patent refers to
`checking a list of authorized users which relates to the first network device.
`And while the '163 patent talks about transmitting a request message back to
`the user's computer it goes on to say that it does that to require that the user's
`computer prove that it has sufficient privileges. Beser doesn't have any of
`those things. Then Apple goes on to argue that, quote, Dr. Monrose --
`JUDGE BISK: Can I just ask you a question about that? So, if what
`you're saying is that Beser should of said, in order to sort the claim language
`you're talking about is that the list of authorized users is for the second
`network device?
`
`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
`26
`
`
`
`16
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`
`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
`26
`
`MR. ZEILBERGER: Can you repeat the question, Your Honor?
`JUDGE BISK: What you just said was that Beser says there's a list of
`authorized users for the first network device?
`MR. ZEILBERGER: No. Sorry, Your Honor, Apple was
`approaching the '163 patent in that, it's our patent not Beser's.
`JUDGE BISK: Okay.
`MR. ZEILBERGER: So, Apple goes on to argue, quote, that Dr.
`Tamassia testified that IPR2014-00237, that the related '697 patent shows
`several ways of determining authorization including simply whether or not
`the requester can access the site being requested. And, again, Apple's
`leaving out critical text on what Dr. Tamassia actually testified to. What he
`actually testified was that determining whether the user has prerequisite
`privileges includes, quote, what credentials the user has and whether or not it
`can access the site being requested. In other words, he testified that if a user
`has the credentials he needs to access a site then that's an indication that they
`have sufficient privileges. Not simply whether they can access the site.
`Then Apple goes on to argue, quote, Patent Owner also ignores the
`disclosure in the '163 patent relating to decryption -- relating decryption to
`authorization and then they cite to the '163 patent on Exhibit 1001, column
`4, lines 45 to 49. And then Exhibit 1055, page 86, lines 16 though page 87,
`line 13 and there's problems with both of those assertions, starting with the
`cite to the '163 patent, Exhibit 1001. In fact, the '163 patent only says -- it
`speaks to encryption technique that makes unauthorized encryption difficult.
`It doesn't relate in any way to any teachings of Beser. And then Monrose's
`testimony in Exhibit 1055 simply speaks to authorized computers receiving
`data, not the sender, not the originating end device, 24. So, in conclusion I
`
`
`
`17
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`would simply encourage the Board to look at the underlying evidence
`carefully because in our view some of the characterizations of that evidence
`are either simply incorrect or are omitting critical details.
`JUDGE EASTHOM: Can I ask you just a quick question about
`Beser? Is it your contention that Beser system's just has the first user, say
`24, the originating person, if that originating device calls in are you
`contending that Beser's just going to let them talk to whoever they ask for
`and it doesn't really matter, they're just going to connect them together so
`there never is an authenticity thing in Beser?
`MR. ZEILBERGER: You mean an authorization, Your Honor?
`JUDGE EASTHOM: Right, right.
`MR. ZEILBERGER: Beser is silent as to any authorization,
`essentially, ambivalent as to who initiates the originating request.
`JUDGE EASTHOM: Okay. That was my question, I appreciate that.
`MR. ZEILBERGER: Yes, Your Honor. If there are no other
`questions we intend to rest on our papers.
`JUDGE EASTHOM: Do you have any questions
`Judge Trock?
`JUDGE TROCK: No, but I was wondering whether the parties were
`going to deal with this Patent Owner's Motion to Exclude.
`MR. ZEILBERGER: Your Honor, we're happy to rest on our papers
`on that issue. We're aware the Board has addressed similar arguments in the
`past and, again, we're happy to rest on our papers on that issue.
`JUDGE TROCK: Okay.
`JUDGE EASTHOM: Thank you, counsel.
`MR. ZEILBERGER: 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
`25
`26
`
`
`
`18
`
`
`
`Case IPR2017-00337
`(Patent 9,038,163 B2)
`
`
`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
`26
`
`MR. LOY: So, a few minor points, Your Honor. The first is I believe
`my co-counsel indicated to me that I just wanted to make one clarification. I
`think I said the third-party network device in Beser associates the private IP
`address of the trusted third-party, 26, to the originating device. I misspoke
`when I said that. It is a third-party network device associating the private IP
`address -- the public IP address of 16. So, I apologize for that misstatement.
`In addressing the authentication issue very briefly if you will turn to slide
`27, actually.
`So, in response to the authorization issue is whether or not there's a
`determination of the authorization to communicate. Beser does explain that
`a request to initiate a VOIP association may require authentication, and if the
`originating device is not authorized the trusted third-party network device
`would reject the request, and therefore a tunnel would never be associated
`between these two originating and end user devices. That's precisely what a
`determination to whether or not the second network device is authorized is
`being called for in the '163 patent.
`JUDGE EASTHOM: I think your friends on the other side are
`contending that the claim language requires there to be authorization with
`the second, the terminating device, in this case I guess Beser so it would be
`26. I think that's what their argument was, I don't -- maybe -- this seems to
`be addressing authorization by the first on the originating device. The
`passage they're talking about there, so maybe we need to look at Claims 21
`and 42.
`MR. LOY: Sure. If you want to pull those up for a moment. So, if
`you see let's just look at 21 for a moment. It's determining whether the first
`network
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
