`
`
`
`Paper No. 33
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`VIRNETX, INC. AND SCIENCE APPLICATION INTERNATIONAL
`CORPORATION,
`Patent Owner
`___________________
`
`Case IPR2014-00238
`Patent 8,504,697
`____________________
`
`Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and STEPHEN C. SIU,
`Administrative Patent Judges.
`
`__________________________________________________________________
`
`Petitioner’s Reply
`
`
`
`
`
`
`
`
`IPR2014-00238
`
`Table of Contents
`
`I. Mr. Fratto’s Expertise is Relevant and Substantial ................................... 1
`
`II. Ground 1: Wesinger Anticipates
`Claims 1-3, 8-11, 14-17, 22-25 & 28-30 ........................................................ 3
`
`A. Wesinger Discloses the “Determining” Step of the Claims ............. 3
`
`B. Wesinger Discloses the Step of “Intercepting . . . a Request to
`Look up an [] [IP] Address” ............................................................. 12
`
`C. Claims 8, 9, 22, and 23 ...................................................................... 13
`
`D. Claims 10 and 29 and Claims 14 and 28 ......................................... 14
`
`E. Claims 2-3, 11, 15, 17, 24-25, 30 ....................................................... 14
`
`III. Ground 2: Wesinger and RFC 2543 Render Claims 4-7 and 18-21
`Obvious ......................................................................................................... 14
`
`IV. Claim Construction ..................................................................................... 15
`
`
`
`
`
`
`
`
`
`
`
`
`ii
`
`
`
`IPR2014-00238
`
`
`The Board correctly found Wesinger to anticipate claims 1-3, 8-11, 14-17,
`
`22-25, and 28-30, and, in view of RFC 2543, to render claims 4-7 and 18-21
`
`obvious. Decision – Institution of Inter Partes Review, Paper No. 15 (“Dec.”) at
`
`14-22. The Board’s determination that the challenged claims are unpatentable is
`
`supported by more than substantial evidence and should be maintained.
`
`I. Mr. Fratto’s Expertise is Relevant and Substantial
`
`Patent Owner devotes more than 8 pages of its Response to an attack on Mr.
`
`Fratto’s supposed lack of expertise and bias. Far more telling is Patent Owner’s
`
`conduct – Patent Owner did not ask Mr. Fratto a single substantive question
`
`about his declaration testimony at his deposition. Patent Owner’s decision to not
`
`test any of Mr. Fratto’s technical opinions shows those opinions are accurate and
`
`well-founded. Moreover, Patent Owner did not identify a single inaccuracy in
`
`Mr.Fratto’s testimony linked to this supposed “bias” and lack of expertise.
`
`Patent Owner’s challenge to Mr. Fratto’s credentials is baseless. Mr. Fratto
`
`has over 15 years of experience in studying, evaluating, testing, and describing
`
`networking, networking security and related technologies. Ex. 1003 ¶ 9. In the
`
`early 1990s he was writing computer programs as part of an IT consulting business
`
`that provided remote office automation. Ex. 1081 at 13:4-14:7. He can write
`
`computer programs in several languages including “C, Pascal, Turbo Pascal,
`
`PERL, PHP, JAVA, Javascript, [and] a little bit of Python,” all of which were self-
`
`
`
`
`
`IPR2014-00238
`
`taught. Ex. 1081 (Fratto Dep. Tr.) at 13:11-14:19. These subject areas are directly
`
`relevant to understanding the state of the art as it relates to the ’697 patent, and
`
`more than qualify Mr. Fratto as an expert in these proceedings.
`
`Patent Owner claims Mr. Fratto is nonetheless unqualified as he “does not
`
`have a master’s degree” – it argues that knowledge cannot be gained through work
`
`experience to qualify a witness as an expert. Resp. at 1-5. Patent Owner’s expert
`
`disagrees – Dr. Monrose testified that someone with substantial work experience in
`
`the “things that are really relevant to understanding [] the state of the art” could
`
`acquire the same level of expertise as someone with a master’s degree. Ex. 1083
`
`(Monrose Dep. Tr.) at 48:8-49:9; see id. at 35:22-36:17, 37:6-11. Patent Owner’s
`
`theory also ignores Fed. R. Evid. 702 (i.e., a witness may qualify “as an expert by
`
`knowledge, skill, experience, training, or education.” (emphasis added)).
`
`Patent Owner’s claim of “bias” rests on a handful of tweets by Mr. Fratto
`
`reflecting his belief that several of Patent Owner’s patents are invalid. Resp. at 5-
`
`8. This is hardly an indicia of bias –institution of this trial and other proceedings
`
`before the Office substantiates the merits of that belief. The tweets at issue do not
`
`even mention VirnetX. At worst, those tweets are consistent with Mr. Fratto’s
`
`declarations and little more than candid reflections of the fact that the patents at
`
`issue in this and related proceedings are invalid. It is also irrelevant that Mr. Fratto
`
`has never found a patent valid – under this metric, Dr. Monrose is also fatally
`
`
`
`2
`
`
`
`IPR2014-00238
`
`biased because he has never found a patent invalid. See Ex. 1083 at 8:7-9. Both
`
`critiques are meaningless – each has only served as an expert in proceedings
`
`involving Patent Owner. Id.; Ex. 1081 at 46:18-22. Patent Owner’s manufactured
`
`“bias” theory is simply an effort to distract the Panel from the merits and can be
`
`ignored – once again, Patent Owner identifies no error in Mr. Fratto’s testimony
`
`linked to this supposed bias. Resp. at 6-8.
`
`II. Ground 1: Wesinger Anticipates Claims 1-3, 8-11, 14-17, 22-25 & 28-30
`
`The Board correctly found that Wesinger anticipates claims 1-3, 8-11, 14-17,
`
`22-25, and 28-30. In response, Patent Owner contends two distinctions exist,
`
`namely: (i) that because Wesinger performs “separate” DNS resolution and
`
`“connection” requests, it does not show the “determining” step of the claims, and
`
`(ii) Wesinger does not disclose an “intercepting” step. Neither contention is
`
`supported by the record in this proceeding, and each must be rejected.
`
`A. Wesinger Discloses the “Determining” Step of the Claims
`
`Wesinger discloses a scheme in which “virtual hosts” at one or more
`
`firewalls are used to create and process requests to establish connections between
`
`requesting client devices and remote hosts. Resp. at 31-36; Ex. 1008 at 3:49-61,
`
`7:16-66, 8:63-65, Fig. 1. The firewalls include a “DNS/DDNS” server – a
`
`specialized DNS module that interacts with the virtual hosts to resolve names of
`
`requested hosts into network addresses and assist in creating connections across
`
`
`
`3
`
`
`
`IPR2014-00238
`
`each firewall. Resp. at 33-34; Ex. 1008 at Figs. 1, 3, 10:25-34. A virtual host is
`
`created at a firewall using a configuration file; once configured the virtual host
`
`determines if a requested connection to the remote host should be allowed or not,
`
`and whether it needs to apply any data processing techniques to the connection
`
`between the two devices. Resp. at 44-45; Ex. 1008 at 14:45-52, 15:54-57, 16:21-
`
`28. None of this is disputed.
`
`What Patent Owner disputes is that Wesinger shows a single “connection
`
`request” that comprises a request to look up an IP address of the remote host, as the
`
`Board found. See Dec. at 15-16; see also Pet. at 17-18, 21-23; Ex. 1003 at ¶¶ 276-
`
`80, 315-20. Essentially, Patent Owner reads Wesinger as describing a system in
`
`which two unrelated requests are made; namely, a first “transparent” DNS query
`
`(which gets resolved into an IP address), and a second, unrelated, “non-
`
`transparent” “connection request” (which establishes a secure communication
`
`link). In particular, Patent Owner contends the firewall checks access rules and
`
`initiates an encrypted connection only in response to an “ensuing connection
`
`request” entirely separate from a request containing a domain name. According to
`
`Patent Owner, this means Wesinger does not disclose determining “in response to a
`
`request to look up an [IP] address” and “initiating a secure communication link.”
`
`Resp. at 32-33, 35, 37-46; Ex. 1083 at 275:16-276:6, 285:1-22.
`
`
`
`4
`
`
`
`IPR2014-00238
`
`Patent Owner’s theory rests on a flawed reading of Wesinger. Patent
`
`Owner, for example, places great emphasis on the statement at 13:6-15 of
`
`Wesinger that “ensuing connection requests” are made to physical firewalls, which
`
`handle authentication and related functions, arguing this shows two “separate”
`
`requests are being made. Resp. at 34, 40, 42-44, 55. Patent Owner and its expert
`
`are simply misreading Wesinger – the quoted text comes from a section explaining
`
`how physical firewalls handle multiple, concurrent connection requests coming
`
`from different sources. As this passage clearly explains:
`
`The configuration of FIG. 4, however, further allows the physical
`firewall machines 407 and 408 to share the aggregate processing load
`of current connections. Load sharing may be achieved in the following
`manner. Each of the DNS modules of all of the machines receive all
`DNS queries, because the machines are connected in parallel.
`Presumably, the DNS module of the machine that is least busy will be
`the first to respond to a query. An ensuing connection request is then
`mapped to a virtual host on the responding least-busy machine.
`
`Ex. 1008 at 13:6-15. Thus, Wesinger is simply explaining its system can scale up
`
`to handle multiple distinct connection requests – it says the first request is handled
`
`by the first available virtual host, and then an ensuing different connection request
`
`is handled by a different virtual host (i.e., it is “mapped to a virtual host on the
`
`responding least-busy machine.”). Id. And each of these connection requests can
`
`contain a domain name requiring resolution. Read accurately, this section of
`
`
`
`5
`
`
`
`IPR2014-00238
`
`Wesinger does not state that there are two separate requests (i.e., one to resolve a
`
`domain name, and a second to request a “connection”). There is only one request,
`
`which contains the domain name requiring resolution and which is used to
`
`establish the secure connection. E.g., Ex. 1008 at 3:54-60, 9:55-60, 10:15-16.
`
`Patent Owner had difficulty explaining how the Wesinger scheme functions
`
`due to this misreading of this patent. Resp. at 35 (“Wesinger is silent on how the
`
`connection request might arise following the DNS query”). That difficulty stems
`
`from Patent Owner’s error in describing how the Wesinger scheme actually works.
`
`Indeed, Dr. Monrose’s deposition testimony contradicts Patent Owner’s “separate”
`
`request theory – as Dr. Monrose acknowledged, “the DNS virtual host receives the
`
`connection request.” Ex. 1083 at 275:16-276:6; see also id. at 283:13-6; 278:9-
`
`291:17. Indeed, Dr. Monrose acknowledged that he had simply assumed the
`
`“ensuing connection request” was different. Id. at 284:2-6. In fact, Dr. Monrose
`
`agreed that claim 1 of the Wesinger patent explicitly states “at the time that the
`
`connection request is issued by the first computer under the claim, there has not
`
`been any DNS resolution yet.” Id. at 253:22-255:2. Indeed, claim 1 of Wesinger
`
`shows no distinction between “DNS” request and a “connection” requests – it
`
`specifies: (i) a connection request containing a domain name issues from a first
`
`computer “specifying the name of the second computer,” (ii) this connection
`
`request containing the name of the second computer is “received by one of the
`
`
`
`6
`
`
`
`IPR2014-00238
`
`virtual hosts,” (iii) “bi-directional connections” between the first computer and the
`
`virtual host, and between the virtual host and the second computer are established,
`
`and (iv) data thereafter passes between the first and second computers through
`
`these bi-directional connections. Ex. 1008 at 17:17-46. Wesinger thus flatly
`
`contradicts Patent Owner’s “separate request” theory, under which a “connection
`
`request” is made only after a DNS name resolution based on an earlier request has
`
`already been completed. See Ex. 1003 at ¶¶ 315-20; see generally Ex. 1083 at
`
`26:10-18, 235:9-255:2, 259:6-22.
`
`Read accurately, there is thus no “second” or “ensuing” connection request
`
`in the Wesinger scheme – the “connection request” is the same request from the
`
`client device that contains the domain name of the remote host requiring name
`
`resolution (i.e., it is a request, inter alia, to look up an IP address of a remote host).
`
`See Ex. 1003 at ¶¶ 290-92; Ex. 1008 at 9:15-25, 36-51. Wesinger shows this
`
`single connection request containing the domain name being received by the
`
`firewall, and in response, the firewall spawns a new virtual host to handle the
`
`connection. Pet. at 16-17; Ex. 1003 at ¶¶ 284-85 (Ex. 1008 at 9:19-25, 36-51;
`
`15:9-12; 16:19-24). Wesinger also explains the DNS module on the firewall will
`
`pass a network address for the remote host directly to the spawned virtual host on
`
`that firewall. E.g., Ex. 1008 at 9:18-19 (“The DNS server for D returns the
`
`network address of D to a virtual host on the firewall 155.” (emphasis added)),
`
`
`
`7
`
`
`
`IPR2014-00238
`
`Fig. 1 (showing host D is connected directly to firewall 155), 9:42-44; Ex. 1003 at
`
`¶¶ 278-80. Wesinger also shows that if the connection requested by the client
`
`device to the remote host is permitted, only then will the virtual host return its own
`
`IP address to the client; if it is not permitted, the request will be denied. Dec. at
`
`14; Ex. 1008 at 3:58-60, 9:22-25; see id. at 14:45-54, 14:66-15:4, 15:54-57. As
`
`Wesinger explains, the firewall determines whether it should allow client C to
`
`connect to host D based on a “myriad of tests,” and access to the virtual host is
`
`denied if it is not allowed. Dec. at 16-17 (Ex. 1008 at 3:54-60, 9:55-60, 10:15-16);
`
`Ex. 1083 at 264:22-265:9. Wesinger also explains that if the channel processing
`
`rules specify the connection should be encrypted, the virtual host will
`
`automatically encrypt all communications between the client and the host. Pet. at
`
`19-20; Ex. 1003 at ¶¶ 305-08; Ex. 1008 at 11:51-60, 36-50. And Wesinger shows
`
`that any type of data can be transmitted between devices, including audio and
`
`video. Ex. 1008 at 11:38-46, 55-58.
`
`Patent Owner theory about “separate” requests also is inconsistent with
`
`Wesinger’s indication that the DNS module – not the client – passes the
`
`connection request to the firewall: “When client C tries to initiate a connection to
`
`host D using the name of D, DNS operates in the usual manner to propagate a
`
`name request to successive levels of the network until D is found.” Ex. 1008 at
`
`9:15-18 (emphasis added), 9:18-19. The name resolution process, thus, is an
`
`
`
`8
`
`
`
`IPR2014-00238
`
`integral part of the process of “initiating a connection” – i.e., a “connection
`
`request.” Tellingly, Patent Owner omits the first clause of the paragraph from
`
`Wesinger it quotes to advance its “separate request” theory. That clause makes
`
`clear the paragraph is describing the process of “initiat[ing] a connection” – it is
`
`not, as Patent Owner contends, describing a separate “DNS” process. (emphasis
`
`added). See Resp. at 32-33 (quoting Ex. 1008 at 9:16-25), 37-38. Patent Owner
`
`does this to misleadingly portray Wesinger as teaching that the DNS step is
`
`unrelated to the “connection request.” As Dr. Monrose conceded at his deposition,
`
`the connection request described in this passage is “going to have the name of D in
`
`the query” and that “DNS operates in its usual manner to propagate that” request.
`
`Ex. 1083 at 258:4-259:12). And indeed, Wesinger clearly shows that each firewall
`
`spawns a virtual host in response to this connection request – it explains a virtual
`
`host on each firewall receives a network address corresponding to host D, and then
`
`the virtual host returns its own address to the computer from which it received the
`
`request. Ex. 1008 at 9:20-25. The result is that client C receives the network
`
`address for the virtual host on its own firewall, which C will use to send data to
`
`host D. E.g., id.; Ex. 1003 at ¶¶ 288-92, 297.
`
`Patent Owner also contends the virtual hosts described at 9:15-25 of
`
`Wesinger are “dedicated virtual hosts” for the DNS modules that handle IP
`
`requests, and that these virtual hosts are distinct from other virtual hosts that
`
`
`
`9
`
`
`
`IPR2014-00238
`
`handle the “separate” connection requests. Resp. at 34. Wesinger does explain
`
`that the DNS modules may be dedicated virtual hosts (such as 115 of Figure 1).
`
`However, it also makes clear that each DNS module returns an address to a
`
`spawned virtual host on its firewall (such as 105a and 105b of Figure 1), and only
`
`then does the spawned virtual host return its own address to the requesting device.
`
`Ex. 1008 at 9:20-25, 42-44; Ex. 1003 at ¶¶ 278-80, 290-92. Wesinger also
`
`explains that when the firewall spawns each new virtual host, it uses a common set
`
`of configuration data – a configuration file, access rules, and channel processing
`
`rules. Pet. at 19-20; Ex. 1003 at ¶¶ 286, 292; Ex. 1008 at 10:13-16; 24-28; 14:45-
`
`52; 15:54-57. Wesinger does not show, as Patent Owner suggests, distinct virtual
`
`hosts performing only “separate” DNS or only “allow/disallow” functions.
`
`Patent Owner next mischaracterizes Figure 3, arguing it is further evidence
`
`that there are two “separate” requests in the Wesinger scheme. Resp. at 34; Ex.
`
`2025 at ¶ 34. But Figure 3 illustrates a “special-purpose virtual host 317,” a type
`
`of virtual host that simply permits a remote host to access the firewall through an
`
`“HTML-based Configurator” in order to edit a configuration file–it has no
`
`relevance to the virtual hosts that act on connection requests. Ex. 1008 at 10-24.
`
`Patent Owner’s reliance on Figure 8 is equally unavailing; that figure shows the
`
`logical structure of the firewall, which is “controlled by [the] daemon,” and which
`
`“spawns a process to handle the connection request” (i.e., “virtual host 810”). Id.
`
`
`
`10
`
`
`
`IPR2014-00238
`
`at Fig. 8; 16:3-28. Wesinger explains the spawned virtual host will receive the
`
`connection request with the name of the remote host, and “operate in the usual
`
`manner to propagate a name request” until the remote hose is found. Ex. 1008 at
`
`9:15-25. Figure 8 and its description actually support Mr. Fratto’s explanation that
`
`Wesinger shows that a client initiates a connection by sending a single connection
`
`request containing a domain name to the firewall, that the firewall works with the
`
`DNS module to resolve the name and spawn virtual hosts to handle the connection,
`
`and that the virtual host processes the connection and returns its own network
`
`address to the client. E.g., Ex. 1003 at ¶¶ 288-92, 297.
`
`Patent Owner also asserts Wesinger’s determination based on access rules
`
`cannot satisfy the claimed “determining” step because the access rules focus on
`
`whether the client is able to access the host and not whether the host is available.
`
`Resp. at 29-31, 46-47. The claims make no such distinction – this argument thus
`
`rests on Patent Owner’s proposed redefinition of the “determining” step to require
`
`it to be based solely on properties of the second device. Resp. at 47. The Board
`
`properly rejected that proposal, as nothing in the ’697 patent or the claim language
`
`compels that meaning. Thus, Wesinger shows the “determining step” as it shows
`
`determining if a host is unavailable for a connection with the client (e.g., if the host
`
`is listed in the deny database or if other parameters of the connection are not met).
`
`Ex. 1008 at 14:45-54, 14:66-15:4, 15:54-57.
`
`
`
`11
`
`
`
`IPR2014-00238
`
`Patent Owner also suggests the only time access rules are checked in
`
`Wesinger is in response to the first data packet. Resp. at 39 (citing Wesinger at
`
`14:6-7 which states “[r]ules checking is performed on [the] first data packet” sent
`
`between the client and the host). That passage, however, is simply one
`
`embodiment in which a process creates a “session” between the client and host for
`
`UDP packets—ordinarily a “connectionless protocol.” Ex. 1008 at 13:66-14:16.
`
`Patent Owner later contradicts itself, stating Wesinger also shows access rules
`
`being checked when a virtual host is spawned. Resp. at 35, 44. And Wesinger
`
`teaches that access rules are checked multiple times in the connection process. Ex.
`
`1008 at 15:46-53 (access allowed only during certain times), 17:1-7; see Ex. 1003
`
`at ¶¶ 305-06. Thus, more than substantial evidence supports the Board’s finding
`
`that Wesinger shows the determining step of claims 1 and 16. Dec. at 16-17.
`
`B. Wesinger Discloses the Step of “Intercepting . . . a Request to
`Look up an [] [IP] Address”
`
`The Board correctly found Wesinger discloses the intercepting step of
`
`claims 1 and 16. As the Board observed, Wesinger teaches that prior art systems
`
`required a user to manually connect to a firewall, and then to provide the firewall
`
`with the name of the remote device. Dec. at 15-16. Wesinger also explains its
`
`invention solves this problem by having the firewall transparently intercept
`
`connection requests, thereby eliminating the need for the user to manually connect
`
`to the firewall each time. Ex. 1008 at 9:35-49. This reading of Wesinger is not
`
`
`
`12
`
`
`
`IPR2014-00238
`
`some disjointed connection of different parts of the Wesinger disclosure – it is how
`
`the Wesinger describes its invention addressing a problem in prior art systems.
`
`Patent Owner next disputes the Board’s authority to institute a ground of
`
`unpatentability using a rationale not identical to that presented in a petition. Resp.
`
`at 48-50. Patent Owner’s theory that the Board has no authority to independently
`
`evaluate the patent claims, prior art and evidence before it and reach independent
`
`determinations on patentability is flatly inconsistent with the inter partes review
`
`statute and rules. Resp. at 48.
`
`Finally, Patent Owner argues Wesinger does not meet its alternative
`
`construction of the “intercepting” step. The Board properly rejected that
`
`alternative construction as it improperly adds unclaimed requirements to that step.
`
`It also renders the claims confusing – the “evaluation” step Patent Owner would
`
`would add is actually part of the next step in the claims (the “determining” step).
`
`Thus, substantial evidence supports the Board’s determination that Wesinger
`
`anticipates claims 1 & 16. Dec. at 15-18.
`
`C. Claims 8, 9, 22, and 23
`
`The Board correctly found Wesinger discloses a mobile device (claims 8 and
`
`22) in the form of a laptop computer claims (9 and 23). Dec. at 18-19. Patent
`
`Owner admits that Wesinger shows use of computers but disputes that Wesinger
`
`teaches “laptop” computers. Resp. at 52-53. A laptop computer is one of two
`
`
`
`13
`
`
`
`IPR2014-00238
`
`types of computers, a fact well-known in February 2000. Ex. 1003 at ¶ 270. In a
`
`predictable art, disclosure of a small genus, discloses every species in that genus.
`
`See Bristol-Myers Squibb Co. v. Ben Venue Labs., Inc., 246 F.3d 1368, 1380 (Fed.
`
`Cir. 2001); see also In re Petering, 301 F.2d 676 (CCPA 1962).
`
`D. Claims 10 and 29 and Claims 14 and 28
`
`The Board correctly found Wesinger discloses the additional limitations of
`
`claims 10 and 29 and of claims 14 and 28. Dec. at 19-20. Patent Owner’s sole
`
`response is to present the same arguments it presents regarding the “determining
`
`step” (i.e., that Wesinger discloses separate “DNS” and “connection” requests, and
`
`that the virtual host is only created in response to the “second” request). Resp. at
`
`53-55. For the reasons presented above (§ II.A), this is incorrect.
`
`E. Claims 2-3, 11, 15, 17, 24-25, 30
`
`Patent Owner did not separately challenge the Board’s findings on these
`
`claims, so they stand or fall with the independent claims from which they depend.
`
`III. Ground 2: Wesinger and RFC 2543 Render Claims 4-7 and 18-21
`Obvious
`
`The Board correctly found that Wesinger in view of RFC 2543 renders
`
`claims 4-7 and 18-21 obvious. Dec. at 21-22. In response, Patent Owner asserts
`
`that Wesinger “teaches away” from integrating a SIP server (described in RFC
`
`2543) into a firewall. Resp. at 56-68. Patent Owner attacks a strawman –
`
`Petitioner did not argue the SIP server would be integrated into the firewall, but
`
`
`
`14
`
`
`
`IPR2014-00238
`
`rather that it was common for organizations to use a single architecture to support a
`
`variety of services, and that architecture could include both firewalls and SIP
`
`servers. Pet. at 30, 31 (“including multiple services, such as a VOIP server and
`
`firewall on a single, common communications architecture was both desirable and
`
`a conventional design technique”); Ex. 1003 at ¶ 310; see id. at ¶¶ 188-90, 309-13,
`
`367-68, 378-80. Patent Owner did not address these points, and never cross-
`
`examined Mr. Fratto on his opinions, so Petitioner’s evidence stands unrebutted.
`
`The Board should maintain its finding that Wesinger and RFC 2543 render claims
`
`4-7 and 18-21 obvious, as that finding is supported by substantial evidence.
`
`IV. Claim Construction
`
`The Board correctly construed the claims in the institution decision. Patent
`
`Owner asserts the Board should reconsider several of those constructions, but only
`
`one of Patent Owner’s proposed constructions could actually affect the analysis of
`
`Wesinger (i.e., the “determining” step). Resp. at 47 (discussing whether the
`
`Wesinger firewall looks “outward” or “inward”). As explained above (§ II.A.1),
`
`no language in the claim requires such a restriction – the claims simply specify
`
`determining . . . whether the second network device is available for a secure
`
`communications service.” If a firewall prevents clients from accessing certain
`
`requested destinations, those destinations are not available to the clients.
`
`Therefore, the Board should maintain its previous findings.
`
`
`
`15
`
`
`
`IPR2014-00238
`
`Dated: November 21, 2014
`
`
`
`
`
`Respectfully Submitted,
`
`/ Jeffrey P. Kushan /
`Jeffrey P. Kushan
`Registration No. 43,401
`Sidley Austin LLP
`1501 K Street NW
`Washington, DC 20005
`jkushan@sidley.com
`(202) 736-8914
`Attorney for Petitioner Apple
`
`
`
`
`
`
`
`IPR2014-00238
`
`Certificate of Service
`
`I hereby certify that on this 21st day of November, 2014, a copy of this
`
`Petitioner’s Reply has been served in its entirety by email on the following counsel
`
`of record for Patent Owner:
`
`
`Joseph E. Palys
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1996
`E-mail: josephpalys@paulhastings.com
`
`Naveen Modi
`Paul Hastings LLP
`875 15th Street NW
`Washington, DC 20005
`Telephone: (202) 551-1990
`E-mail: naveenmodi@paulhastings.com
`
`
`
`
`Dated:
`
`November 21, 2014
`
`Respectfully submitted,
`
`/Jeffrey P. Kushan/
`Jeffrey P. Kushan
`Attorney for Petitioner Apple
`
`
`
`
`
`
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
