Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`DOCKET NO.: 2211726-00145
`Filed on behalf of Unified Patents Inc.
`By: David L. Cavanaugh, Reg. No. 36,476
`Daniel V. Williams, Reg. No. 45,221
`Matthew J. Leary, Reg. No. 58,593
`Wilmer Cutler Pickering Hale and Dorr LLP
`1875 Pennsylvania Ave., NW
`Washington, DC 20006
`Tel: (202) 663-6000
`Email: david.cavanaugh@wilmerhale.com
`
`Roshan Mansinghani, Reg. No. 62,429
`Jonathan Stroud, Reg. No. 72,518
`Unified Patents Inc.
`1875 Connecticut Ave. NW, Floor 10
`Washington, DC, 20009
`Tel: (202) 805-8931
`Email: roshan@unifiedpatents.com
`Email: jonathan@unifiedpatents.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________________________________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________________________________
`UNIFIED PATENTS INC.
`Petitioner
`v.
`PLECTRUM LLC
`Patent Owner
`IPR2017-01430
`Patent 5,978,951
`PETITIONER’S REPLY
`
`
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`TABLE OF CONTENTS
`
`I. 
`II. 
`
`2. 
`
`3. 
`
`Page
`INTRODUCTION ........................................................................................... 1 
`CLAIMS 8 AND 11 ARE OBVIOUS IN VIEW OF CHERITON AND
`JAIN ................................................................................................................. 2 
`A. 
`It was obvious to use Jain’s CRC hash function in place of Cheriton’s
`XOR hash function. ............................................................................... 2 
`1. 
`A POSA would have been motivated to use Jain’s CRC hash
`function in place of Cheriton’s XOR hash function. .................. 3 
`It would have been obvious to try Jain’s CRC hash function in
`place of Cheriton’s XOR hash function. ..................................... 6 
`It would have been obvious to substitute Jain’s CRC hash
`function for Cheriton’s XOR hash function. .............................. 9 
`Responses to Patent Owner’s “questions” about obviousness. 11 
`4. 
`Cheriton discloses an “input packetizer” and an “output packetizer.”
` ............................................................................................................. 12 
`PATENT OWNER FAILS TO PROFFER ANY EVIDENCE THAT
`PETITIONER HAS NOT NAMED ALL REAL PARTIES-IN-INTEREST
` ....................................................................................................................... 15 
`A. 
`The Board already rejected identical RPI arguments in the Nonend
`IPR. ...................................................................................................... 15 
`Petitioner has properly identified the real party-in-interest. ............... 16 
`B. 
`IV.  THE EXPERT’S TESTIMONY SUPPORTS THE PETITION ................... 21 
`V.  ANY QUESTION ON THE CONSTITUTIONALITY OF INTER PARTES
`REVIEW IS MOOT ...................................................................................... 22 
`VI.  THE BOARD SHOULD INSTITUTE REVIEW OF ALL CHALLENGED
`CLAIMS ........................................................................................................ 22 
`VII.  CONCLUSION .............................................................................................. 23 
`
`
`B. 
`
`III. 
`
`i
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`INTRODUCTION
`The Board found that Petitioner demonstrated a reasonable likelihood of
`
`I.
`
`prevailing on Petitioner’s assertion that claims 8 and 11 are obvious over Cheriton
`
`and Jain. Decision (Paper 8) at 18. The Patent Owner does not challenge the
`
`Board’s findings with respect to most of the limitations of those claims. With respect
`
`to the two remaining limitations—for which the Board found ample evidence of
`
`disclosure in the prior art—the Patent Owner’s attorney arguments are both legally
`
`and factually insufficient. These deficiencies are underscored by the Patent Owner’s
`
`lack of expert testimony to rebut any position taken by Petitioner or Petitioner’s
`
`expert, Dr. Seshan.
`
`First, Patent Owner mistakenly argues that there is insufficient evidence to
`
`show that it would have been obvious to use the cyclic redundancy check (CRC)
`
`hash function of Jain in place of the XOR hash function of Cheriton. That argument
`
`is (a) based on a legal premise long-rejected by courts, and (b) is not supported by
`
`the intrinsic or extrinsic evidence nor by expert testimony—it should be rejected.
`
`Second, Patent Owner disputes that Cheriton discloses an “input packetizer”
`
`and an “output packetizer.” But Patent Owner improperly ignores the specific
`
`disclosure of these limitations that Petitioner (and the Board) cites in Cheriton,
`
`including ample disclosure under the Board’s description of “packetizer.”
`
`Finally, the Petitioner has properly identified the real party-in-interest (RPI).
`
`1
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`Patent Owner has failed to proffer any evidence that reasonably brings into question
`
`Petitioner’s identification.
`
`II. CLAIMS 8 AND 11 ARE OBVIOUS IN VIEW OF CHERITON AND
`JAIN
`Patent Owner disagrees for two reasons, both of which are wrong. First, there
`
`are many reasons to combine Cheriton and Jain contrary to the Patent Owner’s
`
`attorney arguments. Second, Cheriton discloses what Patent Owner calls the “Input
`
`Packetizer/Output Packetizer” of claim 8, including under the Board’s view of
`
`“packetizer.”
`
`A.
`
`It was obvious to use Jain’s CRC hash function in place of
`Cheriton’s XOR hash function.
`Instituted claims 8 and 11 both claim a data unit forwarding device with “a
`
`cyclic redundancy code (CRC) generator” that is used to generate “CRC encoded
`
`addresses” from “received source and destination addresses.” The generated CRC
`
`is used as a hash index “lookup” into a cache of address information. ’951 Patent
`
`(EX1001), Fig. 7a, 5:45-57, 8:5-56. The resulting address information can be used
`
`to determine, for example, where to forward the received data units. See Seshan
`
`(EX1007), ¶¶ 33-34, 63.
`
`As the Board reasoned, it would have been obvious to combine Cheriton
`
`(which discloses every limitation except for using an “XOR” hash function to look
`
`up network information) with Jain (which discloses using a CRC for that same
`
`2
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`purpose). Decision at 20 (noting the “interchangeability of hashing functions”);
`
`Seshan Dec. (EX1007), ¶ 82.
`
`Patent Owner asserts that the petition does not “sufficiently explain a rationale
`
`for combining Cheriton and Jain.” Resp. 5. Patent Owner provides no support for
`
`its allegations—indeed, the opposite is true. There are multiple motivations to
`
`combine the teachings of these references. The use of a CRC would also have been
`
`at least (a) obvious to try and (b) obvious as a substitution of one known element for
`
`another to obtain predictable results.
`
`Patent Owner offers no affirmative evidence that a POSA would not have been
`
`motivated to substitute CRCs for XOR functions. Patent Owner points to no
`
`secondary considerations of non-obviousness. And Petitioner’s expert testimony is
`
`unrebutted by any documents or expert testimony.
`
`1.
`
`A POSA would have been motivated to use Jain’s CRC hash
`function in place of Cheriton’s XOR hash function.
`A POSA would have been motivated to use the CRC that Jain discloses as a
`
`hash function instead of the XOR that Cheriton discloses. As explained below, high-
`
`performance CRC functions can lower undesirable hashing “collisions” and were
`
`known to be nearly ‘optimal’ mathematically when compared to XOR functions. See
`
`Hashing Comparison (EX1021), § IV (“CRC provides an almost optimal hashing
`
`function”). CRC functions can also beneficially re-use existing resources in
`
`3
`
`
`

`

`networking devices for calculating CRCs. See Jain (EX1003) at 3:49-4:7; id., 10:46-
`
`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`47.
`
`As background, one measure of quality for a hashing function is how well it
`
`avoids mapping different input values to the same output index. See Hashing
`
`Comparisons (EX1021), Fig. 1, § II. When different inputs result in the same output,
`
`a “collision” occurs. Jain (EX1003), 4:2-7.
`
`In the context of Cheriton, collisions decrease cache performance. There, the
`
`hash function is intended to quickly map network addresses to an index into a cache
`
`of destination ports for those addresses. Cheriton (EX1002), 7:51–53, 10:57–59,
`
`Fig. 3. Thus, a collision can lengthen the time needed to find the information in the
`
`cache, because too many values are stored at the same location/index. See Hashing
`
`Comparisons (EX1021), Fig. 1, § II (explaining that the goal of a hashing function
`
`is to maximize the probability of finding the searched-for data on the first try).
`
`Cheriton notes another advantage to avoiding collisions. Collisions can force
`
`the system to delete an output port mapping that the system learned earlier if there
`
`is no room for a new mapping at the same location. See Cheriton (EX1002), 10:67-
`
`11:5 (a new record “replac[es] the least recently used entry if necessary.”). The next
`
`time a received packet is destined for the originally-mapped address, a cache “miss”
`
`occurs and the system no longer knows where to route the packet, resulting in
`
`additional processing time. Cheriton (EX1002), 10:60-11:5 (describing cache
`4
`
`
`

`

`“misses”).
`
`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`Better hashing functions generally result in fewer collisions. With respect to
`
`avoiding collisions, CRC algorithms were known as “excellent hashing functions,”
`
`particularly when used—as in Cheriton—for network address lookup. Comparison
`
`of Hashing Schemes (EX1021), 1573; Seshan Dec. (EX1007), ¶ 63; Cheriton
`
`(EX1002), 9:34-60. Although hash functions using an XOR can also provide
`
`excellent results in some circumstances, a CRC function “provides an almost optimal
`
`hashing function.” See Hashing Comparison (EX1021), § IV (“CRC provides an
`
`almost optimal hashing function”); see also ’951 patent (EX1001), 2:24-27
`
`(acknowledging the already-known problem of a “high thrash rate” when too many
`
`addresses map to the same row in the cache), 16:1-5, Abstract.
`
`Another motivation for using a CRC in Cheriton was that the hardware to
`
`implement CRCs was already available within network devices such as Cheriton’s
`
`network switch. Jain notes that “the Frame is passed through a cyclic redundancy
`
`check (CRC) circuit. As a result, it has been recognized that the bits of the CRC
`
`provide a mechanism for hashing.” Jain (EX1003) at 3:49-4:7 (noting CRC
`
`processing within known network adapters); id., 10:46-47. Jain also recognized the
`
`value of reducing the required circuitry in network devices (such as by re-using
`
`circuitry). Id. at 11:6-5 (“The combined CAM and hash filter 10 enables significant
`
`savings in circuitry, complexity and power consumption.”).
`5
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`For all these reasons, a POSA would have been motivated to combine
`
`Cheriton and Jain by substituting Jain’s CRC for Cheriton’s XOR hash.
`
`2.
`
`It would have been obvious to try Jain’s CRC hash function
`in place of Cheriton’s XOR hash function.
`Even if the CRC had similar performance to an XOR in certain situations, it
`
`still would have been obvious to try a CRC to fill the already-recognized need for
`
`hashing. For example, it would have been obvious to try a CRC because there was
`
`“a finite number of identified, predictable solutions.” See KSR Int’l Co. v. Teleflex
`
`Inc., 550 U.S. 398, 421 (2007). At the time of the filing of the ’951 patent, and still
`
`to this day, there were a relatively small number of recognized algorithms for
`
`implementing hash functions. See Seshan Dec. (1007), ¶¶ 64, 84, 176-177. The
`
`Hashing Comparison article, published almost five years before the patent, reflects
`
`this point. The article compares some of the better-known hashing algorithms of its
`
`day. Id. at Abstract (“we compared the efficiency of several different hashing
`
`functions such as cyclic redundancy checking (CRC) polynomials, Fletcher
`
`checksum, folding of address octets using the exclusive-OR operation, [etc.]); see
`
`also https://ehash.iaik.tugraz.at/ wiki/ The_Hash_Function_Zoo (last visited Apr.
`
`20, 2018) (identifying various hash function publications). Jain also reflects the
`
`small number of potential choices for a hashing function, noting that the “hash
`
`function generator may employ specific bits of the destination address, a correlation
`
`6
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`of address bits, checksums, or XOR folding.” Jain (EX1003), 6:3-4. Moreover, a
`
`CRC
`
`is a
`
`type of a “checksum” such as
`
`identified
`
`in Jain.
`
` See
`
`https://stackoverflow.com/ questions/ 3357053/ what-the-difference-between-crc-
`
`and-checksum (last visited Apr. 20, 2018).
`
`It would also have been obvious to try a CRC because a POSA would have
`
`had a reasonable expectation of success in using a CRC instead of an XOR. See
`
`KSR, 550 U.S. 398 at 421. CRCs perform well for hashing the same type of data on
`
`which Cheriton’s XOR function was used: network address data. Hashing
`
`Comparison (EX2021) at Introduction. The predictive simulations in that article
`
`were also directed to the same general purpose as both Cheriton and Jain: network
`
`address lookup in network elements.
`
`Moreover, CRC functions were already in use in network elements in 1992.
`
`Hashing Comparison (EX1021) at § IV (“Another hashing function, already used in
`
`a few adapters, is to use bits from the cyclic redundancy check (CRC) of the
`
`address”). The patentee acknowledged that CRCs were already being used for data
`
`validation in prior art network switches, and in response amended the claims to avoid
`
`any “unintended” confusion with that use of CRCs. Seshan Dec. (EX1007) at ¶ 47
`
`(citing File History, Amendment at 2-3 (02/09/99) and U.S. Patent 5,708,659
`
`(“Method for hashing in a packet network switching system”)).
`
`A POSA would also have expected success because it was already well-
`7
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`known to implement CRCs in hardware, like the switching hardware of Cheriton.
`
`See, e.g., Seshan Dec. (EX1007) at ¶ 84 (“It would have been well within the
`
`capabilities of a person of ordinary skill in the art to employ an alternative hash
`
`function”); Hashing Comparison (EX2021), Section IV (“bits extracted from the
`
`CRC of the address can be used as a hashing function that is easy to implement in
`
`hardware.”); Jain (EX1003), 10:46-47 (“the hardware implementation of the
`
`technique through the use of shift registers is straightforward.”). Moreover, as
`
`discussed above, Jain also notes that CRC circuitry was already available in network
`
`devices. Jain at 3-4.
`
`The modular nature of the CRC and XOR functions and the similarities
`
`between each function’s respective inputs and outputs were additional reasons for
`
`expecting success in trying one for the other. Both the disclosed CRC and XOR are
`
`simple, modular functions that rely on one or two input bit patterns and produce a
`
`single output. Compare Jain (EX1003), Abstract to Cheriton (EX1002), Fig. 7
`
`(XOR-ing addresses); see also Seshan Dec. (EX1007) ¶ 30 (“This general process
`
`of using a hash function to search a cache or memory could be applied using many
`
`different search keys”); ¶ 62 (“Cheriton’s cache includes a hash function which
`
`hashes the source and destination address to provide a lookup index for the cache”);
`
`¶ 63 (other hash functions can be used). Moreover, Jain’s CRC used “received
`
`address” data as an input, which is the same input data that Cheriton’s XOR function
`8
`
`
`

`

`was already using. Id., Jain (EX1003), Abstract.
`
`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`Patent Owner contends that the Petition lacks a detailed plan for exactly “how
`
`Jain’s CRC hashing would be incorporated into the system of Cheriton.” Resp. at 6.
`
`But Patent Owner does not dispute that it was possible to use a CRC (such as Jain’s)
`
`instead of an XOR. Resp. at 6. Any minor modifications that might be necessary to
`
`ensure integration would have been within the routine exercise of engineering
`
`judgment. Seshan Dec. (EX1007) ¶ 200.
`
`In any case, obviousness does not require a detailed roadmap on how to
`
`physically put the pieces together in any case. See, e.g., Allied Erecting &
`
`Dismantling Co. v. Genesis Attachments, LLC, 825 F.3d 1373, 1381 (Fed. Cir. 2016)
`
`(“The test for obviousness is not whether the features of a secondary reference may
`
`be bodily incorporated into the structure of the primary reference.”) (citing In re
`
`Keller, 642 F.2d 413, 425 (CCPA 1981)); In re Kahn, 441 F.3d 977, 990 (Fed. Cir.
`
`2006) (“As long as some motivation or suggestion to combine the references is
`
`provided by the prior art taken as a whole, the law does not require that the references
`
`be combined [in a particular manner].”).
`
`3.
`
`It would have been obvious to substitute Jain’s CRC hash
`function for Cheriton’s XOR hash function.
`Using a CRC instead of an XOR would also have been obvious as a simple
`
`substitution of one known element for another because (a) the substitution was
`
`9
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`predictably successful (as just discussed) and (b) because CRCs and XOR were
`
`interchangeable. See, e.g., Seshan Dec. (EX1007) at ¶¶ 177-77, 181. Jain itself
`
`suggests interchangeability between XOR and CRC algorithms:
`
`In a presently preferred embodiment of the invention the hashing
`function generator is a CRC generator, although the teaching of the
`invention is not limited to only the use of a CRC technique. For
`example, the hash function generator may employ specific bits of the
`destination address, a correlation of address bits, checksums, or XOR
`folding.
`Jain at 6:1-4; emphases added. Jain makes no suggestion that exchanging XORs
`
`for CRCs required any special considerations.
`
`Jain also makes an explicit suggestion of interchangeability. Dr. Jain directed
`
`readers to another of his articles that explored alternative hash functions such as the
`
`CRCs and XORs. Hashing Comparison (EX1022), 6:4-6 (suggesting “A
`
`Comparison of Hashing Schemes for Address Lookup in Computer Networks”,
`
`apparently an earlier version of the same-named article at EX1021). The suggested
`
`comparison further supports the choice of hash function as just that—a design
`
`choice.
`
`As the PO acknowledges, Cheriton notes that the XOR function “is used for
`
`illustration only” and that “it will be apparent to anyone skilled in the art that other
`
`hash functions from the one shown can be used.” Cheriton (EX1002), 9:48-51.
`
`10
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`Cheriton’s ambivalence as to particular hash functions further confirms that XOR
`
`and CRC are interchangeable.
`
`The Patentee was similarly ambivalent as to what “coding” (function) was
`
`used to generate a hash index. During prosecution, the patentee indicated that a CRC
`
`was just one potential hashing function, and ascribed no particular significance to
`
`using a CRC. “In the present case, at least a portion of the received data unit is
`
`coded, such as with a cyclic redundancy code, to generate a reduced representation
`
`of that address” (File History, Amendment 02/09/99.)
`
`4.
`Responses to Patent Owner’s “questions” about obviousness.
`The four questions that Patent Owner offers (instead of evidence) in its
`
`Response have been answered. With regard to “(a) how Jain’s CRC hashing would
`
`be incorporated into the system of Cheriton,” as explained above, such an
`
`explanation is not a requirement to show obviousness. See, e.g., Allied Erecting, 825
`
`F.3d at 1381. Even if it were required, for the reasons provided above (regarding
`
`modularity, the identical nature of the interface to a CRC, and the re-use of existing
`
`hardware), such an incorporation would have been well within the ability of a POSA.
`
`With regard to “(b) what effects such incorporation might have,” as above, a
`
`POSA would expect positive effects from using a CRC, such as lower thrashing
`
`and/or re-use of existing hardware resources.
`
`With regard to “(c) why one of skill in the art would seek to change Cheriton’s
`
`11
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`hash function logic,” the above-described benefits are why. Again, Patent Owner
`
`has not provided any reasons a POSA would not consider making the substitution.
`
`With regard to “(d) why replacing the hash function logic with Jain’s CRC
`
`hashing would have been ‘a routine substitution’,” the evidence shows that CRCs
`
`and XORs were interchangeable, and Patent Owner has not offered any evidence—
`
`or even contended—anything to the contrary.
`
`B.
`
`Cheriton discloses an “input packetizer” and an “output
`packetizer.”
`Cheriton discloses both “packetizer” limitations of claims 8 and 11, including
`
`under the Board’s description of “packetizer.”1 Per the Board, “packetizing” refers
`
`to the “assembly” and/or “reformatting” of “units of information or data” that are
`
`“transmitted between devices or components.” Paper 8 at 21. The Board noted that
`
`the term does not “require that ‘packets’ be in a specialized form.” Id.
`
`As applied to an “input packetizer,” the Board cites examples in the ’951
`
`patent where a network interface card (NIC) “strips information out of the received
`
`frame” (such as a protocol ID, source address (SA) and destination address (DA)),
`
`adds CRC data as part of a “hash function,” and sends the reformatted result as a
`
`
`1 Though Patent Owner did not challenge with the Board’s description for
`
`“packetizer” and has failed to analyze the term under that description.
`
`12
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`packet to a cache controller. Id.; ’951 Patent (EX1001), 7:45–50, 7:56-58, 8:29-35.
`
`For “output packetizer,” the Board’s citations describe similar reformatting and
`
`“assembly” of data such as the SA, DA, and output port identifier that is sent from
`
`the cache to the output NIC. Id., 9:16-23. Cheriton performs the same
`
`“packetizing.”
`
`Cheriton discloses the “input packetizer.” Just like the example the Board
`
`cited in the ’951 patent, Cheriton’s hash function processes SA and DA data
`
`(Petition, 64), which Patent Owner does not dispute are reformatted/assembled units
`
`of data from the original frame received at the “input ports.” Resp. 7. Cheriton’s
`
`Virtual Path Cache 415 also participates by assembling that data as inputs to a CRC,
`
`whose output is also assembled data used for later processing. Cheriton (EX1003),
`
`Fig. 7.
`
`The Petition cited “Cheriton, 9:34-38, 10:46-49” which in turn refer to
`
`elements of Figs. 4, 6, and 7. Those figures also disclose some of the data paths and
`
`content of this assembled/reformatted data from the input frames (highlighting
`
`added):
`
`13
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`
`
`
`
`
`
`
`
`Patent Owner suggests that Petitioner pointed solely to Cheriton’s “hash
`
`function logic” for the “input packetizer” and solely to a “tri-state buffer” for the
`
`“output packetizer.” Resp. at 7. Here Patent Owner merely demonstrates that it
`
`ignored the full scope of Petitioner’s citations to Cheriton.
`
`If the Board requires anything more for “input packetizer,” Petitioner also
`
`pointed to disclosure that includes, e.g., “switch hardware 409.” Petition, 64, 21-24.
`
`Patent Owner did not dispute that “Cheriton uses the switch hardware to decode the
`
`source and destination addresses and generate [assemble] a virtual path index for use
`
`in indexing the cache.” Id. at 22 (citing Cheriton (EX1002), 5:32-34, 10:42-45).
`
`Petitioner already noted that switch hardware 409 performed “frame header
`
`14
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`handling” and “frame processing” for input, which relate to the format of the frame.
`
`Id. at 21.
`
`
`
`Cheriton also discloses the “output packetizer,” including under the Board’s
`
`understanding of that term (assembling/formatting data).
`
` As the Board
`
`acknowledged, “Petitioner maps Cheriton’s tri-state buffer, which formats source
`
`and destination address information for placement onto the data bus, as the ‘output
`
`packetizer’.” Paper 8 at 20 (emphasis added).
`
`If the Board requires anything more for “output packetizer,” Petitioner
`
`identified more than just a “tri-state buffer.” Petitioner also pointed to disclosure
`
`that includes “virtual path record” and the bus 633 onto which that data is assembled,
`
`as well as the previously-discussed “switch hardware 409.” Petition, 67-68, 21-24.
`
`Cheriton describes how the switch hardware “forwards and processes the datagram
`
`packet according to the fields of the virtual path record on bus 633 (FIGS. 6 and 4).”
`
`Cheriton 10:57-59. That disclosure also indicates that information for the packet,
`
`including the virtual path record, was assembled onto the bus.
`
`III. PATENT OWNER FAILS TO PROFFER ANY EVIDENCE THAT
`PETITIONER HAS NOT NAMED ALL REAL PARTIES-IN-
`INTEREST
`A. The Board already rejected identical RPI arguments in the
`Nonend IPR.
`The Board has already considered and rejected the same RPI arguments that
`
`15
`
`
`

`

`Patent Owner makes in its Reply. Patent Owner’s arguments are a verbatim copy
`
`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`of the arguments that patent owner Nonend made—and that the Board rejected—
`
`in Unified Patents, Inc. v. Nonend Inventions N.V., IPR2016-00174 (May 12,
`
`2016).2 Id., Paper 10 at 4-6. The minor variations between the POPR in Nonend
`
`and Patent Owner’s reply in this case are primarily the different exhibit numbers.
`
`Compare id., Paper 7 (POPR) at 6-13 to Resp. at 9-15. Patent Owner does not
`
`allege that any relevant facts have changed in the months after Nonend. Thus, the
`
`Board should reject Patent Owner’s arguments for the same reasons the Nonend
`
`panel did.
`
`B.
`Petitioner has properly identified the real party-in-interest.
`Even if the Board had not already rejected Patent Owner’s identical RPI
`
`arguments, the Board should do so here. In compliance with 37 C.F.R. § 42.8(b)(1),
`
`Unified submitted the mandatory notice properly certifying itself as the real party-
`
`in-interest. Petition, Paper 3 at 1. The burden of production then fell on Patent
`
`Owner to provide sufficient rebuttal evidence that reasonably brings the RPI
`
`certification into question. See Atl. Gas Co. v. Bennett Regulator Guards, Inc.,
`
`IPR2013-00453, Paper 88, at 7, 8 (Jan. 6, 2015).
`
`While the inquiry for this question includes several factors, the relevant
`
`
`2 Patent Owner’s counsel here also represented Nonend.
`
`16
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`considerations here are “whether a non-party exercised or could have exercised
`
`control over a party’s participation in a proceeding,” Unified Patents Inc. v. Am.
`
`Vehicular Sci., LLC, IPR2016-00364, Paper 13 (June 27, 2016) at 6, or “whether a
`
`non-party is funding the proceeding or directing the proceeding,” Unified Patents
`
`Inc. v. Hall Data Sync Tech., LLC, IPR2015-00874, Paper 11 (Sept. 17, 2015) at 3.
`
`See Wi-Fi One, LLC v. Broadcom Corp., No. 2015-1944 (Fed. Cir. Apr. 20, 2018)
`
`(slip op. at 1, 18) (confirming the PTAB rule that “[A] party that funds and directs
`
`and controls an IPR […] proceeding constitutes a ‘real party-interest.’”); see also
`
`Zoll Lifecor Corp. v. Philips Elecs. N. Am. Corp., IPR2013-00609, Paper 15 (Mar.
`
`20, 2014) at 10. The Board’s prior decisions specify the type of evidence required
`
`to rebut the RPI certification—i.e., actual evidence that anyone other than Petitioner
`
`“has any control over the instant proceeding” or “is funding the instant proceeding.”
`
`Unified Patents, Inc. v. Clouding IP, LLC, IPR2013-00586, Paper 9 (Mar. 21, 2014)
`
`at 5. Patent Owner provides no such evidence here.
`
`As the Nonend panel reasoned, Patent Owner’s argument “provides no
`
`evidence that any other entity is controlling this particular proceeding, or is
`
`providing direct financing for this particular proceeding.” Nonend Inventions N.V.,
`
`IPR2016-00174, Paper 10, at 6. Since then, the Federal Circuit has confirmed the
`
`Board’s approach. Patent Owner identified neither evidence nor reasoning
`
`suggesting that Petitioner’s certification of RPI is incorrect.
`17
`
`
`

`

`No evidence exists because the Petitioner is transparent about its aims and
`
`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`its
`
`business model.
`
`
`
`See
`
`Unified
`
`Patents
`
`Inc.,
`
`FAQ,
`
`https://www.unifiedpatents.com/faq/ (last visited Apr. 6, 2018) (“Unified retains
`
`sole and absolute discretion regarding all aspects of any challenge.”).
`
`Patent Owner suggests that one or more members of Unified are additional
`
`real parties-in-interest and/or are providing direct financing for this particular
`
`proceeding. But Patent Owner’s own statements and evidence refutes that
`
`suggestion. Patent Owner concedes that Petitioner provides a range of services
`
`and activities other than filing IPR petitions. Patent Owner refers to “Unified’s
`
`defensive patent activities” generally, and not as restricted to work with the Patent
`
`Office. Resp. at 10. Patent Owner’s exhibits note that Unified also provides
`
`services such as “patent troll monitoring, market intelligence, and advisory
`
`services.” EX2004 at 3.
`
`Instead of evidence, Patent Owner rehashes arguments that the Board has
`
`repeatedly rejected. Patent Owner tries to apply RPX (and In re Guan which RPX
`
`cites) but the Board has distinguished those cases. Resp. at 12 (citing RPX Corp. v.
`
`VirnetX, Inc., IPR2014-00171, Paper 52 at 9 (June 23, 2014)). The Board previously
`
`found the comparison to In re Guan to be “misplaced,” because
`
`[a]mong other reasons, in Guan, there was evidence that
`unnamed parties picked the patents to be challenged and
`
`18
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`
`provided funding for the particular proceedings.
`In contrast, the record here indicates that, in this
`proceeding, Petitioner is acting without control from its
`subscribers and is not receiving financing from them to
`bring this particular proceeding.
`
`Unified Patents Inc. v. iMTX Strategic, LLC, IPR2015-01061, Paper 9 (Oct. 15,
`
`2015) at 6. Similarly, the Board distinguished RPX where,
`
`in the RPX cases, the evidence demonstrated that the
`actions of RPX and Apple were like certain prohibited
`behavior discussed in In re Guan . . . which stated that an
`entity named as the sole real party in interest may not
`receive a suggestion from another party that a particular
`patent should be the subject of a request . . . and be
`compensated by that party for the filing of the request . . .
`of that patent without naming the party as a real party-in-
`interest who suggested and compensated the entity for the
`filing of a request for inter partes reexamination of the
`patent. Here, the present record does not demonstrate that
`any of Petitioner’s members suggested or compensated
`Petitioner for the filing of the Petition challenging [the
`challenged] patent.
`
`Unified Patents Inc. v. Dragon Intellectual Property, LLC, IPR2014-01252, Paper
`
`37 (Feb. 12, 2015) at 8-13 (citations and quotations omitted) (emphasis in
`
`original).
`
`19
`
`
`

`

`Petitioner’s Reply in Support of Petition
`IPR2017-01430
`
`The Board has consistently confirmed Unified’s position. Unified’s more
`
`than 100 certifications in inter partes review petitions as to real party-in-interest
`
`have, for the past several years, been upheld by the Board every time they have been
`
`considered.3 This IPR is being conducted in the same manner as the others before
`
`the Board in the years prior.
`
`Finally, Patent Owner is wrong that RPI is a jurisdictional issue requiring
`
`termination; rather, binding Board precedent holds otherwise. Lumentum Holdings,
`
`Inc. v. Capella Photonics, Inc., IPR2015-00739, Paper 38 (Mar. 4, 2016)
`
`(precedential) (“a lapse in compliance with those requirements does not deprive the
`
`Board of jurisdiction over the proceeding, or preclude the Board from permitting
`
`