`
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`IPR2015-00866, Paper No. 38
`IPR2015-00868, Paper No. 38
`IPR2015-00870, Paper No. 38
` IPR2015-00871, Paper No. 38
`July 19, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`VIRNETX INC.,
`Patent Owner.
`____________
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
` IPR2015-00871 (Patent 8,560,705 B2)
`,
`____________
`
`Held: June 27, 2016
`____________
`
`
`
`
`
`BEFORE: KARL D. EASTHOM, JENNIFER S. BISK, and
`GREGG I. ANDERSON, Administrative Patent Judges.
`
` The above-entitled matter came on for hearing on Monday, June
`27, 2016, commencing at 1:30 p.m., at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`
`
`
`
`
`
`
`JEFFREY P. KUSHAN, ESQ.
`THOMAS A. BROUGHAN, III, ESQ.
`SCOTT M. BORDER, ESQ.
`Sidley Austin
`1501 K Street, N.W.
`Washington, DC 20005
`
`JOSEPH E. PALYS, ESQ.
`NAVEEN MODI, ESQ.
`DANIEL ZEILBERGER, ESQ.
`CHETAN R. BANSAL, ESQ.
`Paul Hastings LLP
`875 15th Street, N.W.
`Washington, DC 20005
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 2
`
`
`
`
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE BISK: This is the oral hearing for IPRs
`2015-00866, 00868, 00870 and 00871, Apple versus VirnetX.
`Each side has 40 minutes. May I have the parties tell who's here
`for counsel?
`MR. KUSHAN: Good afternoon, Jeff Kushan, Tom
`Broughan and Scott Border for Apple, we're from Sidley Austin.
`JUDGE BISK: Patent Owner?
`MR. PALYS: Good afternoon, Your Honor, Joseph
`Palys joined by Naveen Modi, Daniel Zeilberger and Chetan
`Bansal on behalf of VirnetX.
`JUDGE BISK: Please begin when you're ready. Please
`remember to speak into the microphone for Judge Anderson.
`MR. BROUGHAN: Your Honor, I have copies of our
`demonstratives, if I may approach?
`MR. ZEILBERGER: Your Honor, may I approach, too,
`to provide our demonstratives?
`JUDGE BISK: Sure.
`MR. BROUGHAN: If I could reserve 15 minutes for
`rebuttal, please.
`JUDGE BISK: Sure.
`MR. BROUGHAN: Good afternoon, Your Honors, and
`may it please the Board. We are here to discuss four proceedings
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`involving three patents owned by VirnetX, the '341 patent, the
`'131 patent and the '705 patent. The first three proceedings
`involve the Beser reference, Exhibit 1007 and the RFC 2401
`reference, Exhibit 1008. The final proceeding involves the
`Aventail reference, which is Exhibit 1009, and also several other
`references.
`If you could go to slide 3, please. The three patents at
`issue today have claims with very similar claim limits. Claim 15
`of the '341 patent, shown here on the screen, is exemplary. Claim
`15 specifies a method for creating a virtual private network
`communication link between a first network device and a second
`network device and the method is comprised of four steps. The
`first step is sending the request to look up an IP address.
`The second step has two parts within it, the first is
`intercepting the request and then making a determination that the
`second network device is available. In the second step, the first
`network device receives an indication that the second network
`device is available, it receives a requested IP address, as well as
`provisioning information for a virtual private network
`communication link.
`In the third step, it specifies connecting to the second
`network device, over the virtual private network communication
`link, and in the fourth step, information is communicated between
`the first device and second device over that.
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`The basic steps of claim 15 of the '131 patent are nearly
`identical, except they specify creating a secure communication
`link instead of a VPN communication link. And the claim also
`specifies that audio or video data are transmitted over the link.
`Claim 1 of the '705 patent is similar to the '131 claims, although
`it's structured a little bit differently.
`Now, many of the claim elements that are at issue in the
`patents here today are very similar to those claims that we
`discussed several weeks in IPR2015-00810, 811 and 812. Those
`claims similarly recited a request to look up an IP address based
`on a domain name and the steps of intercepting the request and
`making a determination that the second network device is
`available.
`For the claim elements in the -- for the claim elements
`that the patents at issue today have in common with the patents
`you considered last week, the parties' arguments are largely the
`same, so today I want to focus on the unique aspects of the '341,
`'131 and '705 claims, as well as the parties' arguments with
`respect to them.
`Slide 6, please. This is a summary of the main issues --
`of the main disputes between the parties involving the Beser and
`RFC 2401 references. Today, I would like to focus on the first
`two, but first, before addressing the first disputed issue, I would
`like to briefly recap the Beser system.
`
` 5
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`Go to slide 7. Now, you considered the same slide
`several weeks ago in the 810 proceeding, so I will keep this very
`short. Depicted on the screen are figures 1 and 6 from the Beser
`patent, as well as the IPsec case 3 architecture from page 25 of
`RFC 2401.
`As you can see in figure 1, Beser describes a method for
`creating an IP tunnel between an originating device 24 and a
`terminating device 26. The tunnel is created with the assistance
`of a first network device 14, a second network device 16, and a
`trusted third party network device 30.
`On the bottom left, you see the IPsec case 3 diagram. It
`describes an architecture that is analogous to the architecture
`shown in Beser figure 1. It shows two end devices
`communicating via two intermediate security gateways, SG1 and
`SG2. These two gateways are analogous to the first and second
`network devices in Beser. And in our papers, we explain that a
`person of ordinary skill in the art implement Beser would have
`considered this case-to-be diagram of RFC 2401 to implement
`end-to-end encryption between the originating device and the
`terminating device, as depicted between H1 and H2 in RFC 2401.
`Now, on the right is figure 6 of Beser, and it describes
`the basic process for establishing an IP tunnel in that patent. It
`shows that the originating device sends out a request containing
`the domain name of the terminating device. The request is
`
` 6
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`processed by the devices in Beser's system, and ultimately the
`originating device receives an IP address for the terminating
`device, as well as additional information that it uses to
`communicate with the terminating device via a secure IP tunnel.
`Slide 9, please. This is claim 15 of the '341 patent, and
`I would like to focus in on the first disputed issue, which is the
`term "a virtual private network communication link." I note that
`a similar term, "VPN link," is used in dependent claims in the
`'131 and '705 patents. The independent claims of the '131 and
`'705 specify a secure communication link, and I note that Patent
`Owner does not challenge that Beser and RFC 2401 teach a
`secure communication link.
`Slide 10, please. At the top of the screen are the parties'
`proposed constructions for the term "VPN communication link."
`This comes from page 14 of the 866 petition and page 8 of Patent
`Owner's response. Now, while there are some differences
`between the parties' constructions, none of those constructions
`matter in this case.
`If you go to slide 12, please. This passage from page 31
`of Patent Owner's response is its sole challenge to whether Beser
`and RFC 2401 teach a VPN communication link. And I would
`ask you to make two observations about this passage. The first is
`that Patent Owner does not address either party's construction of
`the term "VPN communication link." Instead, it focuses on a
`
` 7
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`comment in Beser where Beser states that its tunnelling method is
`different than one prior art technique for creating a VPN, but that
`passage says nothing about whether Beser's tunnel is a VPN
`communication link within the meaning of the challenged claims
`here.
`
`And the second observation about this passage is that
`Patent Owner addresses Beser alone, where Petitioner's position
`is based on the combination of Beser and RFC 2401.
`Go back to slide 10, please. At the bottom of the screen
`is a passage from page 31 of our 866 petition, and we explain that
`in the combined system, there will be end-to-end encryption
`between the two end devices in the Beser system as taught by
`RFC 2401, and communications between them would be
`anonymous as taught by Beser.
`So, as we explained in the petition, the combination of
`Beser and RFC 2401 would satisfy either party's construction of
`this term. And I want to make one final note, which is that in IPR
`2014-00237, and in the final written decision, the Board
`considered RFC 2401 and Beser and found that it taught a VPN
`communication link, and that's at pages 41 to 43.
`Patent Owner offers no new theory in these proceedings
`and no reason for this panel to depart from the Board's previous
`and correct determination.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 8
`
`
`
`
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`Slide 16, please. The second disputed issue that I would
`like to discuss today is whether Beser and RFC 2401 teach
`"securely transmitting audio or video data." At the top of the
`screen is a dependent claim from the '341 patent which contains
`that limitation, and at the bottom of the screen are two limitations
`from the independent claims of the '131 and '705 patents.
`Slide 17. So, in our papers, we explain -- pardon me.
`These are passages from our 866 petition at pages 31 to 33, and
`we explain that a person of ordinary skill in the art would have
`modified -- would have implemented Beser in view of RFC 2401
`to provide end-to-end encryption even when streaming audio or
`video data are transmitted between the end devices.
`Now, Patent Owner has asserted that Beser teaches
`away from the use of encryption with audio and video data, but
`that's not accurate.
`Slide 23. As we have explained, Beser at column 1, line
`54 to 58, recognizes that traffic sent over the Internet ordinarily is
`encrypted; however, it goes on to recognize that even though
`encryption can protect the content of a communication,
`encryption does nothing to protect the identities of the parties
`who are communicating. And in Beser at column 2, lines 1
`through 5 shown at the bottom, Beser explains that even if you
`can encrypt the contents, the lack of anonymity between
`encrypted communications creates security problems.
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`So, Beser goes on to explain that he's describing a
`tunnelling method that's intended to solve this problem and
`designed to be combined with encryption to solve the problem of
`non-anonymous communications.
`If you go back to slide 20. This is a passage from
`Beser, column 1, lines 60 to 67, and Patent Owner relies on this
`passage to assert that Beser teaches away from encrypting audio
`or video data, but this passage doesn't teach away, this passage
`simply notes that if a person of ordinary skill is going to
`configure a system to encrypt streaming audio or video data, that
`system should have sufficient computing power to handle the
`load.
`
`We had our expert, Dr. Tamassia, consider this passage
`and others in the patent, and he came to the conclusion that a
`person of ordinary skill in the art would have combined Beser
`with encryption, and encrypted data -- and would have encrypted
`even streaming audio and video data transmitted between the end
`devices. And you can see that in Exhibit 1005 at paragraphs 427
`to 428.
`
`Slide 19. And, finally, in the final written decision in
`IPR2014-00237, the Board considered this same issue, whether --
`and the Board concluded that Beser and RFC 2401 at the very
`least suggest encrypting audio and video data sent between them.
`Patent Owner offers no new theory in these proceedings, and no
`
` 10
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`reason for this panel to depart from its previous and correct
`determination.
`Slide 22. There are several other main areas of dispute
`between the parties, but you considered these issues last week or
`several weeks ago in the 810 and 812 proceedings. So, rather
`than rehash the arguments from those proceedings, unless the
`Board has any questions, we will rest on the explanations in our
`papers for these and I will move on to the Aventail reference.
`(No response.)
`MR. BROUGHAN: Slide 59. The 871 proceeding
`involves the Aventail reference and the '705 patent. The '705
`patent also is at issue in the 870 proceeding involving Beser.
`Slide 63. So, there are two main disputes between the
`parties with respect to Aventail: Whether Aventail and the RFCs
`teach a determination; and whether Aventail and the RFCs teach
`a secure communication link, or a VPN link -- and a VPN link.
`Slide 60. I would like to start with a brief overview of
`the Aventail system. On your screen, you will see a figure from
`page 72 of Aventail and a passage from page 10. Aventail
`describes methods and systems for creating a VPN between a
`mobile user and resources located on a private network. At the
`bottom of your screen, you'll see a mobile user connected to the
`public Internet. The mobile user's computer runs the Aventail
`Connect client software.
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`On the left of your screen you will see the Aventail
`VPN server, which is also called the Aventail ExtraNet server.
`The ExtraNet server sits at the edge of a private network, which
`you can see running across the top of the screen. The Aventail
`ExtraNet server works with the Aventail Connect client software
`to authenticate remote users and allow those users to securely
`access resources located on the private network.
`Slide 64. Thank you. This is claim 1 of the '705 patent,
`and I would like to start with the first disputed issue between the
`parties, which is whether Aventail and the RFCs teach a
`determination as a result of the request that the target device is a
`device with which a secure communication link can be
`established.
`Slide 65. These are several passages from pages 38 to
`39 of our 871 petition. And in our petition, we explained how
`two different components of the Aventail system teach the
`claimed determination. The Aventail Connect client software and
`the Aventail ExtraNet server.
`Regarding the determination by the Aventail client
`software, when an application on a mobile device attempts to
`connect to a server that's located on the private network, it makes
`a DNS request that contains the host name of the server. That
`DNS request is intercepted by the Aventail client software, and
`the host name is compared to a table of redirection rules. If it
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`matches a redirection rule, the request is flagged, and it will later
`be proxied to the ExtraNet server for processing.
`By checking the host name in the DNS request against a
`redirection rule, Aventail Connect makes a determination that as
`a result of the request that the server is a device with which a
`secure communication link could be established.
`Go to slide 69. This is two passages from page 39 and
`40 of our 871 petition. We also explained how the ExtraNet
`server makes a determination as a result of the request. When a
`request has been marked for proxying to the Aventail Connect
`server, the host name will be forwarded to the ExtraNet server
`and the ExtraNet server will process it to create a connection
`between the client device and the target device. As part of that
`processing, it will perform a SOCKS negotiation, and in the
`SOCKS negotiation, it will consult what Aventail calls access
`control rules.
`Slide 71. This is from page 19 of Aventail, Exhibit
`1011. Now, Aventail explains that access control rules allow an
`administrator to specify various rules that govern whether users
`can access the private network. And as this passage shows,
`unless an administrator specifies which users, which are people in
`groups, can remotely access the private network, and it also lets
`an administrator specify what machines can be remotely
`accessed.
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`And, so, during the SOCKS negotiation, the ExtraNet
`server will check these access control rules to determine whether
`the user is permitted to remotely access the network, and also
`whether the requested machine is available to that user. So, by
`checking these access control rules, Aventail ExtraNet server
`makes the determination that the requested machine is a device
`with which a secure communication link can be established.
`Slide 76, please. The second disputed issue with
`respect to the Aventail and DRCs is whether they teach a secure
`communication link. As shown here on the screen are claims 16
`and 21 of the '705 patent, and as you can see, a VPN link is a type
`of secure communication link. At the bottom of the screen are
`the parties' proposed constructions for the term "secure
`communication link." These come from pages 11 and 12 of the
`871 petition and page 5 of Patent Owner's response.
`So, I have two points about the parties' constructions.
`The first is that the Board need not adopt a specific construction
`because Aventail -- the combination of Aventail and RFC 2401
`satisfy both.
`Slide 78. Shown here are two figures from page 60 of
`Aventail, as well as the IPsec case 4 diagram from page 26 of
`RFC 2401. Now, we explain that a person of ordinary skill in the
`art would have modified Aventail or would have configured
`Aventail to provide end-to-end encryption between the Aventail
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`Connect client software and the target device, which in the figure
`is denominated as the final destination.
`JUDGE EASTHOM: Why would you encrypt beyond
`the private ExtraNet server if it's already secure back there behind
`that server?
`MR. BROUGHAN: Well, Your Honor, the client might
`be accessing sensitive information, such as accounting
`information or personnel information, and so there would be a
`reason to protect the communication even on the private network
`so that other people on the private network can't access it.
`As an example, you know, the PTO is a very large
`organization, and even though all PTO employees are on the
`network, you might not want everyone having access to the same
`information.
`And, so, we explained in our papers that a person of
`ordinary skill in the art would have configured Aventail in this
`manner based in part on the teachings of case 4 in RFC 2401.
`And case 4 describes an architecture that's analogous to the
`Aventail system. You will see H1, which is a host that's
`connected to the public Internet, and that's analogous to the
`Aventail Connect software. You will see a security gateway 2 at
`the edge of a local Internet, that's analogous to the Aventail
`ExtraNet server, and a host 2 on the local Internet behind the
`security gateway 2, that's analogous to the final destination.
`
` 15
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`And case 4 shows how it will be -- how you can
`configure this architecture to have one security association
`between the hosts on the Internet and the security gateway. And
`then to have another security association directly between the
`host 1 and host 2, and that's encrypted. So, we explained that a
`person of -- that the combined teachings of these two references
`would satisfy the limitations of the secure communications link of
`the challenged claims.
`If you go back to slide 76. And the second point that I
`wanted to bring up about the term "secure communication link" is
`that if the Board feels the need to adopt a construction, it should
`adopt Petitioner's proposed construction, because Patent Owner's
`construction is inconsistent with the broadest reasonable
`interpretation of the claims.
`In particular, Patent Owner's construction includes the
`requirement that a secure communication link be a direct
`communication link, but it is unclear from the specification what
`the term "direct" means. As Patent Owner points out at pages 8
`to 9 of its response, the specification shows secure
`communication links that span firewalls, edge routers and other
`devices. But Patent Owner never states what is required to make
`a communication indirect, and there are no examples in the
`specification of that either.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 16
`
`
`
`
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`
`Patent Owner's proposed construction is based on an
`alleged prosecution history disclaimer made during prosecution
`of related patents, but when you consider all of Patent Owner's
`statements with respect to this term, there can be no clear and
`unequivocal disclaimer of nondirect communications.
`For example, in the related litigation, Patent Owner
`initially contended that there was no clear disclaimer of nondirect
`communications. While a District Court ultimately didn't agree
`with Patent Owner, Patent Owner's assertion about the scope of
`its claim terms should be taken into account under the broadest
`reasonable interpretation.
`Slide 81. And I'll note that in the final written decision,
`in IPR2014-00481, the Board considered the prosecution history
`disclaimer argument and it rejected that argument as being
`inconsistent with the broadest reasonable interpretation of the
`claims, and Patent Owner offers no new theory in these
`proceedings and no reason for this panel to depart from its
`previous and correct determination.
`Very briefly, I have one other issue to address, Your
`Honors, and that's the prior art status of the Aventail references
`and the RFCs. If you will go to slide 88, please. So, we
`explained that RFCs are published as of the date listed on their
`face, and substantial evidence in the record supports our position.
`We submitted testimony from Dr. Tamassia, who explained that
`
` 17
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`RFCs were published and widely distributed as of the date listed
`on their face, and that this fact was well known to those in the art
`who knew that you could go to the IETF's website to download
`them.
`
`We also submitted RFC 2026, which is Exhibit 1036,
`that describes the IETF's publication practices. We further
`provided testimony from an IETF corporate representative who
`described the IETF's publication practices and testified
`unequivocally that RFC 2401 was publicly available as of the
`date on its face, November 1988.
`And, finally, we submitted industry publications that are
`dated from before the challenged patents' priority date, and those
`publications document that a person of ordinary skill in the art
`would have known to go to the IETF's website, and that at least
`some did go to the IETF's website to download RFC 2401.
`So, the evidence confirms that RFC documents that we
`rely on were publicly available and widely disseminated well
`before February 2000.
`Slide 82, please. With respect to the Aventail reference,
`we explain that it was widely available to those in the art by no
`later than January 1999. We submitted several pieces of evidence
`in support of this, including declarations from three witnesses
`with personal knowledge of Aventail's publication. Their
`testimony is all consistent and it's also consistent with magazine
`
` 18
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`articles and newspaper articles, again, from prior to -- from
`before the priority date of the challenged patents, that document
`that persons in the art received the Aventail product prior to
`February 2000.
`JUDGE EASTHOM: Isn't there some inconsistency
`between Chris Hopen's declaration and some of the articles that
`appear prior to the 1999 date, January? I think Patent Owner
`points out there was a few articles attached to his exhibit that they
`were dated 1997, 1998, but he was -- they were talking about I
`guess Aventail Connect. I didn't -- I think there was a couple of
`dates floating around, so I wasn't sure how that played out, if you
`could tell us that.
`MR. BROUGHAN: Yes, Your Honor. I believe what
`you are referring to is statements in the Chester declaration about
`a 1998 date. If you could go to slide 84, please.
`Now, if you look in paragraph 15 at the top of the
`screen, this is a passage from Exhibit 1022, and Mr. Chester was
`an IT -- head of IT at IBM, which is one of Aventail's largest
`clients, and he explained that he received both evaluation and
`production copies of the Aventail software. And he further
`explained that he was personally involved in Aventail's strategic
`planning and direction about this product.
`And, so, while he testified that he received some of
`these products before January 1999, that's because IBM received
`
` 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
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`them earlier, earlier than the rest of the public. However, he also
`testified that he recalled that Aventail began distributing this
`product no later than mid -- publicly distributed the product no
`later than mid-January 1999.
`So, I believe that is the issue at hand filed by Patent
`Owner. And as you can see from here, there is no actual
`inconsistency, it's just Mr. Chester received it earlier.
`JUDGE EASTHOM: So, I mean, I think in Christopher
`Hopen's declaration, he says in the fall of 1998, Aventail
`announced a product called the Aventail ExtraNet Center, Exhibit
`B is a copy of that, and it's an October 1998 Aventail press
`release. So, you're saying that -- it seems like these press releases
`came out before you're saying that he -- that Aventail released
`these documents and also released the product. Is that true, or
`how do you --
`MR. BROUGHAN: Well, Your Honor, all these dates
`are well before the February 2000 publication date, or the
`February 2000 priority date of the challenged patents. So,
`whether they are -- whether they were distributed in late 1998 or
`early 1999, they were still distributed over a year ahead of the
`publication -- a year ahead of the priority date of the challenged
`patents.
`
`And, you know, in the petition when we were
`explaining this issue, we took a conservative position. While
`
` 20
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`some -- while there is some evidence that it was distributed as
`early as the end of 1998, we can see from the declarations of the
`three witnesses, and from the articles, that it was definitely
`distributed no later than mid-January 1999.
`JUDGE EASTHOM: With respect to the direct
`requirement in the Federal Circuit case --
`MR. BROUGHAN: Yes, Your Honor?
`JUDGE EASTHOM: -- Cisco v. VirnetX -- VirnetX v.
`Cisco, I'm sorry, 767 F.3d. 1308, did the parties agree that direct
`was a requirement in the jury trial, or how did that term get into
`the claim construction?
`MR. BROUGHAN: Pardon me, Your Honor. Yes,
`Your Honor. We agreed to use that construction in the context of
`the District Court litigation, but I would simply point out that in
`the District Court litigation involved several different variables
`that aren't at issue here. One, it's a different claim construction
`standard; two, there was different art at issue, it was the Kiuchi
`reference, whereas here we're talking about Beser and Aventail;
`third, you know, it's a different standard of proof. Clear and
`convincing evidence in the District Court, as well as it's
`preponderance of the evidence here.
`And the records of these proceedings are also different.
`The record has developed in such a manner that it is apparent that
`there is -- that Patent Owner has not clearly and unequivocally
`
` 21
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`IPR2015-00866 (Patent 8,458,341 B2)
`IPR2015-00868 (Patent 8,516,131 B2)
`IPR2015-00870 (Patent 8,560,705 B2)
`IPR2015-00871 (Patent 8,560,705 B2)
`
`disclaimed direct communications because if you look at the
`record of this proceeding and the related proceedings, it is uncl