Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`
`Patent Owner.
`
`____________
`
`Case IPR2019-00823
`Patent 9,712,494
`
`____________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`
`
`
`U.S. Pat. No. 9,712,494
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`
`Patent Owner.
`
`____________
`
`Case IPR2019-00823
`Patent 9,712,494
`
`____________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`Page
`
`I.
`II.
`
`INTRODUCTION ........................................................................................... 1
`CLAIM CONSTRUCTION ............................................................................ 4
`A.
`The “Mobile Computer” Limitation ...................................................... 4
`III. THE PETITION FAILS TO SHOW A REASONABLE LIKELIHOOD
`THAT THE RFC3104-GRABELSKY COMBINATIONS RENDER THE
`CLAIMS OBVIOUS (ALL CLAIMS, ALL GROUNDS) ............................. 6
`A.
`“The Intermediate Computer Does Not Have The Cryptographic Key
`To Decrypt The Encrypted Data Payload” (All Claims) ...................... 7
`1. The Combination Does Not Say Anything About This Limitation . 7
`2. The Petitioner Ignores What The Combination Actually Does Say
` ................................................................................................... 19
`“The Intermediate Computer Configured To Receive From A Mobile
`Computer A Secure Message Sent To The First Network Address”
`(All Claims) ......................................................................................... 22
`1. Petitioner’s Argument That “Either RFC3104’s Host Y Or X”
`Could Be A “Mobile Computer” Whose Address Would
`Change Is Unclear And Unsupported ....................................... 23
`2. RFC3104’s “Roadwarrior” Scenario Does Not Teach The “Mobile
`Computer” Limitation ............................................................... 27
`a.
`Overview Of RFC3104’s “Roadwarrior Scenario” ........ 27
`b.
`The Petition Incorrectly And Inconsistently Maps Both
`RSIP Client X And Host Y To The Claimed “Mobile
`Computer” ....................................................................... 32
`RFC3104’s Roadwarrior Scenario Does Not Involve
`“Mobility” As Claimed and Described in the Patent ..... 45
`i
`
`B.
`
`
`
`c.
`
`
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`3. RFC3104 Teaches Away ................................................................ 49
`IV. CONCLUSION .............................................................................................. 51
`
`
`
`
`
`
`ii
`
`
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`TABLE OF AUTHORITIES
`
`Page
`
`COURT DECISIONS
`
`AC Techs. S.A. v. Amazon.com, Inc.,
`912 F.3d 1358 (Fed. Cir. 2019) .............................................................................. 9
`Arendi S.A.R.L. v. Apple Inc.,
`832 F.3d 1355 (Fed. Cir. 2016) ............................................................................ 24
`Belden Inc. v. Berk-Tek LLC,
`805 F.3d 1064 (Fed Cir. 2015) ............................................................................. 23
`DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc.,
`567 F.3d 1314 (Fed. Cir. 2009) ............................................................................ 51
`Diebold Nixdorf, Inc. v. Int’l Trade Comm’n,
`899 F.3d 1291 (Fed. Cir. 2018) ............................................................................ 17
`DSS Tech. Mgmt. Inc. v. Apple Inc.,
`885 F.3d 1367 (Fed. Cir. 2018) ..................................................................... 24, 25
`In re Nuvasive,
`842 F.3d 1376 (Fed. Cir. 2016) ............................................................................ 24
`International Business Machines Corporation v. Iancu,
`759 F. App’x 1002 (Fed. Cir. 2019) ............................................................ passim
`Personal Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) .............................................................................. 24
`Polaris Indus., Inc. v. Arctic Cat, Inc.,
`882 F.3d 1056 (Fed. Cir. 2018) ............................................................................ 51
`AGENCY DECISIONS
`
`Am. Honda Motor Co. v. Blitzsafe Tex., LLC,
`IPR2016-01473, Paper 9 (PTAB Jan. 24, 2017) .................................................. 17
`
`
`iii
`
`
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`Apple Inc. v. Papst Licensing GmbH & Co.,
`IPR2016-01863, Paper 35 (PTAB Apr. 13, 2018) ........................................ 17, 18
`Ciena Corp. v. Oyster Optics, LLC,
`IPR2018-00070, Paper 54 (PTAB May 9, 2019) ................................................. 24
`Cisco Sys., Inc. v. Oyster Optics, LLC,
`IPR2017-01881, Paper 29 (PTAB Feb. 26, 2019) ............................................... 25
`Facebook, Inc. v. Uniloc USA, Inc.,
`IPR2017-01524, Paper 7 (PTAB Dec. 4, 2017) .................................................. 43
`Kinetic Techs., Inc. v. Skyworks Sols., Inc.,
`IPR2014-00529, Paper 8 (PTAB Sept., 23, 2014) ........................................ 17, 18
`Merck Sharp & Dohme Corp. v. Microspherix LLC,
`IPR2018-00393, Paper 43 (PTAB July 8, 2019) .................................... 12, 16, 19
`
`Snap Inc. v. Vaporstream, Inc.,
`IPR2018-00397, Paper 36 (PTAB June 28, 2019) .................................. 13, 16, 19
`Unified Patents Inc. v. Societa Italiana Per Lo Sviluppo Dell’Elettronica S.P.A.,
`IPR2017-00565, Paper 13 (PTAB June 15, 2017) ........................................ 17, 18
`STATUTES
`
`35 U.S.C. § 316 ........................................................................................................ 12
`RULES AND RULEMAKING
`
`37 C.F.R. § 42.100 ..................................................................................................... 4
`37 C.F.R. § 42.108 ..................................................................................................... 1
`83 Fed. Reg. 51,340, 51,358 (Oct. 11, 2018) ............................................................. 4
`
`
`
`
`
`
`
`
`iv
`
`
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`EXHIBIT LIST
`
`2001
`
`U.S. Pat. No. 8,346,949 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`v
`
`
`
`
`
`INTRODUCTION
`MPH Technologies Oy (“Patent Owner”) submits this Preliminary Response
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`I.
`
`to the Petition for Inter Partes Review by Apple Inc. (“Petitioner”) on claims 1-11
`
`of U.S. Patent No. 9,712,494 (Exhibit 1001) (“the ’494 Patent”). The Petition
`
`should be denied because it fails to demonstrate a reasonable likelihood that at
`
`least one claim is unpatentable under the proposed grounds. 37 C.F.R. § 42.108(c).
`
`The ’494 Patent is a continuation of U.S. Patent No. 8,346,949 (“the ’949
`
`Patent”) [Ex. 2001] that Petitioner has challenged simultaneously in IPR2019-
`
`00822. Petitioner challenges both Patents using the same three references, and its
`
`arguments against the Patents are similar in both petitions. The claims of the
`
`present ’494 Patent, however, include at least two elements not found in claim 1 of
`
`the ’949 Patent, and not addressed in IPR2019-00822, which provide further
`
`reasons why institution of this Petition should be denied.
`
`The Petition asserts that claim 1 of the ’494 Patent is obvious over a
`
`combination of RFC3104 and Grabelsky. However, these references teach methods
`
`significantly different from the claimed invention.
`
`First, the Petition fails to establish a reasonable likelihood that RFC3104 and
`
`Grabelsky teach that “the intermediate computer does not have the cryptographic
`
`key to decrypt the encrypted data payload” as all claims require. Petitioner asserts
`
`
`
`1
`
`
`
`that RFC3104 “forwards the packet to its destination without the need to decrypt
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`any portion of the packet or be aware of any encryption/authentication keys.” But
`
`Petitioner’s cited support in RFC3104 is silent on whether the alleged intermediate
`
`computer, RSIP server N, does or does not, in fact, have a cryptographic key to
`
`decrypt the encrypted data payload, either for forwarding the packet, or for other
`
`purposes. Infra § III-A. Silence does not meet Petitioner’s burden to show that the
`
`alleged prior art intermediate computer does not have a cryptographic key to
`
`decrypt the encrypted data payload. And worse yet, Petitioner fails to address what
`
`RFC3104’s framework actually does say about the examination of data payloads at
`
`that computer. This limitation addresses what the ’494 Patent identifies as “clearly
`
`a major security problem.” The claimed invention addresses that problem. Apple
`
`fails to show that the proposed combination does so.
`
`Second, the Petition fails to establish a reasonable likelihood that RFC3104
`
`and Grabelsky teach the “mobile computer,” or intermediate computer configured
`
`to receive messages therefrom, as the claims require. Petitioner’s assertion that
`
`“RFC3104’s host Y or X could be (and often would be) a ‘mobile computer’”
`
`combines and conflates different embodiments of RFC3104 in ways that are not
`
`taught in the cited art. Indeed, the Petition’s argument relies on attorney argument
`
`
`
`2
`
`
`
`and unsupported opinion testimony directly contrary to the express disclosures in
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`the combination, which, in fact, teaches away from this limitation. Infra § III-B.
`
`The two deficiencies mentioned above are examples of the Petition’s
`
`reliance on conclusory, ipse dixit attorney argument to fill the gaps of its
`
`combinations. The accompanying opinion testimony does no more than parrot
`
`those conclusory attorney arguments without adding objective support.
`
`In summary, the Petition fails to show a reasonable likelihood of prevailing
`
`against claim 1. All other challenged claims (2–11) depend from claim 1, and
`
`include the same limitations and the same gaps in the Petition’s combinations.
`
`Institution of inter partes review should be denied.1
`
`
`
`1 Because partial institution is not permitted, this Preliminary Response only
`
`addresses selected arguments sufficient to dispose of the Petition as a whole. For
`
`example, the Petition relies on a third reference, Wagner, in additional
`
`combinations as to additional limitations of dependent claims 6 and 7. Pet., 59-64.
`
`The Petition relies solely upon RFC3104 and Grabelsky for all other limitations of
`
`all remaining challenged claims, including claims 6 and 7. Pet., 20-64. There is
`
`no contention that Wagner cures the deficiencies of RFC3104 and Grabelsky.
`
`Therefore, this preliminary response does not address Wagner.
`
`
`
`3
`
`
`
`CLAIM CONSTRUCTION
`The Petition was filed after November 13, 2018, the date of the Office’s
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`II.
`
`adoption of the Phillips claim construction standard for IPRs. That familiar
`
`standard therefore applies here, and the claims must be construed “in accordance
`
`with the ordinary and customary meaning of such claim as understood by one of
`
`ordinary skill in the art and the prosecution history pertaining to the patent.” 83
`
`Fed. Reg. 51,340, 51,358 (Oct. 11, 2018) (codified at 37 C.F.R. § 42.100(b)).
`
`Patent Owner disagrees with claim constructions used or implied in the
`
`Petition for various claim terms. However, only one of them—the “mobile
`
`computer” limitation—need be considered at this stage “to resolve the
`
`controversy” against institution. Vivid Techs., Inc. v. Am. Science & Eng’g, Inc.,
`
`200 F.3d 795, 803 (Fed. Cir. 1999).
`
`A. The “Mobile Computer” Limitation
`
`The “mobile computer” recited in the claims should be construed to require
`
`a computer that is capable of moving from one network to another while
`
`maintaining a connection. Said another way, the claims should be construed to
`
`distinguish the claimed “mobile computer” from a computer that is only capable of
`
`static connections.
`
`
`
`4
`
`
`
`Claim 1 recites, in part, “the intermediate computer configured to receive
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`from a mobile computer a secure message.” Ex. 1001 [’494 Patent], cl. 1
`
`(emphasis added). The ’494 Patent explains that
`
`In this text, the term mobility and mobile terminal does not only mean
`physical mobility, instead the term mobility is in the first hand meant
`moving from one network to another, which can be performed by a
`physically fixed terminal as well.
`
`Ex. 1001 [’494 Patent], 4:34-38 (emphasis added).
`
`The very next sentence in the ’494 Patent differentiates the term “mobile”
`
`from static connections. It explains that “[t]he problem with standard IPSec is thus
`
`that it has been designed for static connections.” Ex. 1001 [’494 Patent], 4:39-40
`
`(emphasis added).
`
`Other portions of the specification support construing the claim term
`
`“mobile computer” to require a computer that is capable of moving from one
`
`network to another while maintaining a connection. See also, e.g., id., 5:16-22
`
`(describing prior art method that “provides mobility for the connection” but incurs
`
`various problems); 6:32-34 (explaining that “[e]specially, the object of this
`
`invention is to forward secure messages in a way that enables changes to be made
`
`in the secure connection”) (emphasis added); 7:51-55.
`
`
`
`5
`
`
`
`Therefore, the Patent makes clear that when it is using the terms mobility or
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`mobile, such as in the claimed “mobile computer,” it means a computer that is not
`
`limited to static connections where, for example, “the end points of an IPSec tunnel
`
`mode SA are fixed,” id., 4:41-42, and instead is referring to a computer which can
`
`move from one network to another while maintaining a connection.
`
`Thus, the term “mobile computer,” as recited in the claims, should be
`
`construed to require a computer that is capable of moving from one network to
`
`another while maintaining a connection.
`
`III.
`
`THE PETITION FAILS TO SHOW A REASONABLE LIKELIHOOD
`THAT THE RFC3104-GRABELSKY COMBINATIONS RENDER
`THE CLAIMS OBVIOUS (ALL CLAIMS, ALL GROUNDS)
`The Petition fails to show a reasonable likelihood of prevailing against
`
`independent claim 1, and, therefore, also against all other challenged dependent
`
`claims (Claims 2-11), because, in particular, the Petition fails to show a reasonable
`
`likelihood of demonstrating that the proposed combination of RFC3104 with
`
`Grabelsky would render obvious the claim limitations discussed below. Infra
`
`§§ III-A–III-B. These limitations are all recited in the only challenged independent
`
`claim, claim 1. If any one of them has not been sufficiently demonstrated to have a
`
`reasonable probability of being obvious the Petition under the Petition’s proposed
`
`grounds, institution must be denied.
`
`
`
`6
`
`
`
`“The Intermediate Computer Does Not Have The Cryptographic
`Key To Decrypt The Encrypted Data Payload” (All Claims)
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`A.
`
`The Petition fails to substantiate its assertion that RFC3104 teaches that “the
`
`intermediate computer does not have the cryptographic key to decrypt the
`
`encrypted data payload” as all claims require. Ex.1001, [’494 Patent], cl. 1.
`
`Petitioner relies exclusively on RFC3104 for this limitation.
`
`Petitioner’s argument fails for two independent reasons. First, the Petition
`
`fails to identify any RFC3104 disclosure concerning whether its alleged
`
`“intermediate computer” has cryptographic keys. Silence alone is not enough to
`
`render the limitation obvious. Second, the Petition completely fails to address
`
`what the RFC3104 framework actually does disclose about examining payloads.
`
`In short, the Petition barely even attempts to show that this limitation is met, and
`
`its attempt is woefully inadequate to meet its burden to show a basis for institution.
`
`1.
`
`The Combination Does Not Say Anything About This
`Limitation
`As explained in the ’494 Patent, the intermediate computer not having the
`
`cryptographic keys is a significant feature of the invention, as it prevents the
`
`intermediate computer from having access to possibly sensitive data, which the
`
`’494 Patent explains would be a major security problem. Ex. 1001 [’494 Patent],
`
`6:18-20 (“Having decrypted packets of various customer networks in plaintext
`
`
`
`7
`
`
`
`form in the intermediate host is clearly a major security problem.”). Despite the
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`importance of this limitation, the Petition dedicates only two sentences to its
`
`argument that this limitation of all the claims is met.
`
`The Petition’s entire argument with respect to the alleged obviousness of this
`
`limitation is as follows:
`
`With respect to element [1G], packets arriving at RSIP server N are
`demultiplexed based on parameters accessible from the IP header and
`the IPSec protocol header. RFC3104, 5; Goldschlag Decl., ¶123. Server
`N then searches for a “matching mapping” using these fields and
`forwards the packet to its destination without the need to decrypt any
`portion of the packet or be aware of any encryption/authentication keys,
`or establish a new connection. RFC3104, 5; Goldschlag Decl., ¶123.
`
`Pet., 50.
`
`This brief argument fails to identify any disclosure, or even any mention
`
`whatsoever, of this limitation in RFC3104. Petitioner cites only one page of
`
`RFC3104, page 5. That page is, at best, absolutely silent on whether the alleged
`
`intermediate computer, RSIP server N, does or does not have a cryptographic key
`
`to decrypt the encrypted data payload. As such, the Petition’s showing is deficient
`
`with respect to this element.
`
`Silence does not suffice for Petitioner to meet its burden of showing that the
`
`alleged prior art’s intermediate computer does not have a cryptographic key, as
`
`
`8
`
`
`
`claim 1 of the ’494 Patent and its dependents require. Although depending on the
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`circumstances “a reference need not state a feature’s absence in order to disclose a
`
`negative limitation,” AC Techs. S.A. v. Amazon.com, Inc., 912 F.3d 1358 (Fed. Cir.
`
`2019), RFC3104’s silence here is dispositive. The cited disclosure of RFC3104
`
`does not even disclose secure forwarding of the encrypted data payload, which is
`
`expressly recited in the challenged claims, let alone the decrypting of that payload
`
`that is the subject of the intermediate computer limitation at issue here. What is
`
`more, as will be explained in the next section, infra § III-B.2, the Petitioner
`
`completely fails to acknowledge or address what the RFC3104 framework actually
`
`does say concerning examining data packet payloads, and makes no attempt
`
`whatsoever to reconcile these disclosures with its two-sentence argument that this
`
`limitation is somehow met by page 5 of RFC3104, which is silent on the issue.
`
`Of course, a limitation sometimes can be taught by a reference without that
`
`reference containing an explicit disclosure expressly setting forth the limitation.
`
`For example, in Sud-Chemie, Inc. v. Multisorb Technologies, Inc., 554 F.3d 1001,
`
`1004-05 (Fed. Cir. 2009), the limitation required “uncoated” film. That limitation
`
`was permissibly found to be disclosed by a prior art reference that disclosed a film,
`
`“did not describe the film as coated[,] and did not suggest necessity of coatings.”
`
`AC Techs., 912 F.3d at 1367 (citing Sud-Chemie, 554 F.2d at 1004-05). And in AC
`
`
`
`9
`
`
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`Technologies, a limitation required copying data “independently of an access of the
`
`computer unit.” Id. at 1363. That limitation was permissibly found to be disclosed
`
`by a reference where the reference made clear that it taught copying that did not
`
`“requir[e] access of” the computer unit during copying, and taught copying the
`
`data between units without regard to whether the “computer unit” was one of those
`
`units or not. Id. at 1367. The facts here are quite different. As mentioned above,
`
`and explained further below, the cited disclosure is silent about whether
`
`RFC3104’s alleged secure forwarding does not require the RLSI server to have a
`
`cryptographic key (infra § III-A.2).
`
`The Petition’s deficient argument with respect to this limitation is much like
`
`the deficient unpatentability argument that the Federal Circuit recently rejected in
`
`International Business Machines Corp. v. Iancu, 759 F. App’x 1002 (Fed. Cir.
`
`2019) (nonprecedential), and multiple Board cases that have applied IBM to reject
`
`similar arguments. IBM reversed a finding by the Board that a prior art reference
`
`anticipated the claims at issue, ruling that there was no substantial evidence
`
`supporting the Board’s conclusion that that reference taught the claimed absence of
`
`a feature by its “silence” concerning whether that feature was present or absent.
`
`Id. at 1008-1012.
`
`
`
`10
`
`
`
`The Board in IBM had construed the patent’s “single-sign-on operation” to
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`mean “a process by which a user is authenticated at a first entity and subsequently
`
`not required to perform another authentication before accessing a protected
`
`resource at a second entity.” Id. (emphasis added). The patent owner argued that a
`
`prior art reference, Mellmer, did not meet this limitation via the use of an
`
`accessCard resulting in a second user authentication, arguing that the user of such a
`
`card would be required to perform another authentication. Id. The Board found
`
`otherwise, agreeing instead with the IBM petitioner’s argument that the reference
`
`was silent as to what information was included on the accessCard, and thus taught
`
`a process involving only one user authentication. Id.
`
`The Federal Circuit reversed. The Court explained that “silence” did not
`
`meet the petitioner’s burden to show the limitation of no requirement to perform
`
`another user authentication:
`
`The overall finding that this portion of Mellmer teaches a process
`involving only one user authentication action is not supported by
`substantial evidence. To begin with, even if the Board were correct that
`Mellmer is “silent” about the content of the accessCard, that
`characterization would not alone support a finding that there was no
`user authentication action in this scenario if, as appears, the Board
`meant that it simply could not tell one way or the other whether the
`accessCard contains credentials. Silence in that sense would not by
`
`
`
`11
`
`
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`itself suffice for the Petitioner to meet its burden to prove, by a
`preponderance of the evidence, that there was no user authentication
`action in this scenario. See 35 U.S.C. § 316(e).
`
`Id. (emphases added). Thus, the Court explained, “silence . . . by itself” in the
`
`cited reference, id., does not suffice for a petitioner to meet its burden of showing
`
`the absence a particular process or feature in the prior art.
`
`
`
`The Board has referred to IBM on at least two occasions in support of
`
`findings that petitioners have failed to meet their burden of showing a negative
`
`limitation, or other claimed absence, by silence in the prior art. Specifically, in one
`
`IPR the claims at issue included the limitation: “the hormone is not an anti-
`
`neoplastic agent.” Merck Sharp & Dohme Corp. v. Microspherix LLC, IPR2018-
`
`00393, Paper 43, 66 (PTAB July 8, 2019). The Board’s final written decision
`
`rejected the petitioner’s challenge to the claims, finding that the silence in the cited
`
`prior art could not meet the petitioner’s burden to show that this limitation was
`
`obvious. As the Board explained: “[w]e determine that Petitioner has not satisfied
`
`the negative limitation that the hormones disclosed in Zamora's device are not for
`
`treating cancer, such as prostate cancer. Silence as to whether a hormone is anti-
`
`neoplastic is not sufficient.” Id. (citing IBM, 759 F. App’x at 1011).
`
`
`
`12
`
`
`
`Similarly, in Snap Inc. v. Vaporstream, Inc., the Board construed the claim
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`at issue to require “an arrangement of displays that enables reduced traceability of
`
`electronic messages (e.g., by separately displaying identifying information and
`
`message content).” IPR2018-00397, Paper 36, 8-9 (PTAB June 28, 2019). Based
`
`on this construction, the Board emphatically rejected the petitioner’s argument that
`
`absence of content in the prior art sufficed to render obvious that message content
`
`was absent from other disclosed information. The petitioner’s position was that the
`
`prior art reference, Wren, “teaches the separation of header information and
`
`message content because there is no message content in Figure 9A.” Id. at 32
`
`(emphasis by Board) (citing IBM, 759 F. App'x at 1002, 1010-1011). The Board
`
`rejected Petitioner’s argument. Id. The Board explained that these “facts [we]re
`
`similar to those of [IBM]” and that, as in IBM, the reference’s mere silence was not
`
`sufficient to teach the limitation: “Wren’s silence as to what the ‘New Movie’ text
`
`represents and where it originated is insufficient for Petitioner to prove that it is not
`
`message content.” Id. at 31-32. The Board therefore rejected the argument. Id.
`
`Consistent with these cases, Petitioner here has failed to meet its burden to
`
`show any likelihood that RFC3104 renders obvious the ’494 Patent’s limitation
`
`that “the intermediate computer does not have the cryptographic key to decrypt
`
`the encrypted data payload.” Ex. 1001 [’494 Patent], cl. 1 (emphasis added). To
`
`
`
`13
`
`
`
`begin with, as noted above, this claimed feature is critical to accomplishing the
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`express purpose of the limitation in question, which is, inter alia, “to securely
`
`forward the encrypted data payload to the destination address.” Ex. 1001, [’494
`
`Patent], cl. 1 (emphasis added). As the specification of the ’494 Patent explains:
`
`with the method of the invention the confidentiality of the packets is
`not compromised, while simultaneously having no extra overhead
`when compared to standard IPSec. The intermediate computer does not
`know the cryptographic keys used to encrypt and/or authenticate the
`packets, and can thus not reveal their contents.
`
`
`Ex. 1001, [’494 Patent], 10:32-37 (emphasis added). This is just an example of the
`
`patent’s disclosure; the specification is replete with discussion of the intermediate
`
`computer not having the cryptographic key and the important role of this absence
`
`in the secure forwarding disclosed and claimed. See, id., e.g., 6:10-14; 6:67-7:3;
`
`14:46-55; 19:19-23; 21:50-54.
`
`As noted above, the Petition’s entire analysis with respect to this claim
`
`element (which the Petition refers to as element [1G]) is only two sentences long.
`
`Pet., 49-50. However, the Petition’s assertion that RFC3104 “forwards the packet
`
`to its destination without the need to decrypt any portion of the packet or be aware
`
`of any encryption/authentication keys” only attempts to show, at most, that it is not
`
`necessary to have the cryptographic key for the purpose of forwarding the packet.
`
`
`
`14
`
`
`
`Pet., 49-50 (emphasis added). The Petition relies on RFC3104’s discussion of
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`arrival of packets at RSIP server N, demultiplexing of a “minimum tuple” of
`
`demultiplexing fields, and use of these fields with a “matching mapping” for
`
`forwarding the packet. Id. (citing Ex. 1004 [RFC3104], 5). Petitioner concedes,
`
`however, that RFC3104’s disclosure does not include the format of the packets and
`
`the mapping mechanism. See Pet., 23 (“RFC3104 does not explicitly disclose the
`
`entire format of the IPSec packets or a particular mapping mechanism.”); id., 45
`
`(“RFC3104 does not explicitly disclose how RSIP server N searches for a
`
`‘matching mapping’”).
`
`More to the point, the page of RFC3104 that the Petition’s two-sentence
`
`argument repeatedly cites as support (Ex. 1001, [RFC3104], 5) is silent on whether
`
`the alleged intermediate computer, RSIP server N, does or does not in fact have a
`
`cryptographic key to decrypt the encrypted data payload. Petitioner simply argues
`
`that, based on this silence, “Server N then searches for a ‘matching mapping’ using
`
`these fields and forwards the packet to its destination without the need to decrypt
`
`any portion of the packet or be aware of any encryption/authentication keys.” Pet.
`
`49-50 (emphasis added).
`
`Even taken on its own terms, Petitioner’s argument fails. First, Petitioner’s
`
`argument is that it is not necessary for RSIP server N to have the cryptographic key
`
`
`
`15
`
`
`
`for the purpose of forwarding the packet. Critically, however, Petitioner does not
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`even argue that RFC3104 securely forwards the packet. Pet., 49 arguing merely
`
`that (“Server N … forwards the packet…”).
`
`Next, even if Petitioner’s assertion that RFC3014 “forwards the packet to its
`
`destination without the need to decrypt” is taken as true for purposes of argument,
`
`neither that assertion, nor the cited support in RFC3104, clarifies one way or the
`
`other whether RSIP server N does or does not in fact have a cryptographic key to
`
`decrypt an encrypted data payload, either for the limited purpose of forwarding
`
`packets or for any other purpose. Silence in this respect does not by itself suffice
`
`to show that RFC3014 discloses what is claimed: that “the intermediate computer
`
`does not have the cryptographic key to decrypt the encrypted data payload.”
`
`Ex.1001, [’494 Patent], cl. 1 (emphasis added). As in IBM, 759 F. App’x at 1011,
`
`“[s]ilence in that sense would not by itself suffice for the Petitioner to meet its
`
`burden to prove, by a preponderance of the evidence, that there was no [recited
`
`claim element] in this scenario.” See also, e.g., Merck Sharp & Dohme Corp.,
`
`IPR2018-00393, Paper 43, 66; Snap, IPR2018-00397, Paper 36, 31-32. Unlike
`
`past cases where disclosures of negative limitations have been found, there is, at
`
`best, simply no basis here to “tell one way or the other whether” RFC3104’s server
`
`
`
`16
`
`
`
`N has a cryptographic key to decrypt an encrypted data payload. IBM, 759 F.
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`App’x at 1011.
`
`Beyond the Petition’s reliance on a limited portion of RFC3104, its only
`
`other support is the conclusory assertions of Dr. Goldschlag, who again just largely
`
`parrots the attorney argument in the Petition. Compare Pet., 49-50 with Ex. 1002
`
`[Goldschlag Decl.], ¶123. Such parroting declarations are not evidence. Am.
`
`Honda Motor Co. v. Blitzsafe Tex., LLC, IPR2016-01473, Paper 9, 16-17 (PTAB
`
`Jan. 24, 2017); Kinetic Techs., Inc. v. Skyworks Sols., Inc., IPR2014-00529, Paper
`
`8, 15 (PTAB Sept., 23, 2014); Apple Inc. v. Papst Licensing GmbH & Co.,
`
`IPR2016-01863, Paper 35, 27 (PTAB Apr. 13, 2018); Unified Patents Inc. v.
`
`Societa Italiana Per Lo Sviluppo Dell’Elettronica S.P.A., IPR2017-00565, Paper
`
`13, 13 (PTAB June 15, 2017); see also Diebold Nixdorf, Inc. v. Int’l Trade
`
`Comm’n, 899 F.3d 1291, 1300-1302 (Fed. Cir. 2018); 37 C.F.R. §42.65(a). In
`
`such circumstances, the Board routinely denies Petitions like this one relying on
`
`expert testimony that merely repeat arguments from the petitions. See, e.g., Am.
`
`Honda Motor Co. v. Blitzsafe Tex., LLC, IPR2016-01473, Paper 9, 16-17 (PTAB
`
`Jan. 24, 2017) (“relying on the Geier Declaration as support is insufficient, when,
`
`as here, the cited paragraphs in the Declaration are repeated in the Petition
`
`verbatim, and, thus, offer no more explanation or factual support than what appears
`
`
`
`17
`
`
`
`in the Petition.”) (citation omitted, emphasis added); Kinetic Techs., Inc. v.
`
`Case IPR2019-00823
`U.S. Pat. No. 9,712,494
`
`
`Skyworks Sols., Inc., IPR2014-00529, Paper 8, 15 (PTAB Sept. 23, 2014) (denying
`
`institution) (“Merely repeating an argument from the Petition in the declaration of
`
`a proposed expert does not give that argument enhanced probative value.”); Apple
`
`Inc. v. Papst Licensing GmbH & Co., IPR2016-01863, Paper 35, 27 (PTAB Apr.
`
`13, 2018); Unified Patents Inc. v. Societa Italiana Per Lo Sviluppo
`
`Dell’Elettronica S.P.A., IPR2017-00565, Paper 13, 13 (PTAB June 15, 2017)
`
`(denying institution) (declaration “merely repeats, verbatim, the language of the
`
`Petition.”); 37 C.F.R. § 42.65(a).
`
`The only point that Dr. Goldschlag arguably makes beyond what is in the
`
`Petition is that, “[i]ndeed, this is th
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
