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

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