UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.
`
`Petitioner
`
`v.
`
`UNILOC 2017 LLC
`
`Patent Owner
`
`IPR2019-00701
`
`PATENT 8,018,877
`
`PATENT OWNER SUR-REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.
`
`Petitioner
`
`v.
`
`UNILOC 2017 LLC
`
`Patent Owner
`
`IPR2019-00701
`
`PATENT 8,018,877
`
`PATENT OWNER SUR-REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`Table of Contents
`
`
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................... 3
`
`PETITIONER’S REPLY UNDERSCORES DEFICIENCIES OF THE
`PETITION ....................................................................................................... 3
`
`A.
`
`B.
`
`Petitioner’s reliance on Kirmse as disclosing “transmitting a request to
`a server to allocate a network address and port associated with the
`server to use in a data exchange session with a participating mobile
`device” remains deficient (Ground 1) (Independent Claims 1, 8, 15) . 3
`
`Petitioner’s reliance on the combination of Chambers and RSIP as
`disclosing “transmitting a request to a server to allocate a network
`address and port associated with the server to use in a data exchange
`session with a participating mobile device” remains deficient
`(Ground 2) (Independent Claims 1, 8, 15) ..........................................10
`
`C.
`
`Petitioner’s assertion that a POSITA Would Have Combined
`Cordenier and TURN remains deficient (Ground 3) ..........................16
`
`III. APJs are Unconstitutionally Appointed Principal Officers ...........................22
`
`IV. CONCLUSION ..............................................................................................22
`
`CERTIFICATE OF COMPLIANCE .......................................................................23
`
`CERTIFICATE OF SERVICE ................................................................................24
`
`
`
`
`
`
`
`ii
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`I.
`
`INTRODUCTION
`
`Uniloc 2017 LLC (“Uniloc” or “Patent Owner”) submits this Sur-Reply in
`
`IPR2019-00701 for Inter Partes Review (“Pet.” or “Petition”) of United States
`
`Patent No. 8,018,877 (“the ’877 Patent” or “Ex. 1001”) filed by Apple Inc.
`
`(“Petitioner”).
`
`II.
`
`PETITIONER’S REPLY UNDERSCORES DEFICIENCIES OF THE
`PETITION
`
`Petitioner’s Reply underscores the deficiencies of the Petition’s reliance on
`
`Kirmse, Chambers, RSIP, Cordenier, and TURN and its failed mappings to the
`
`limitations recited in claims 1-20 of the ‘877 Patent.
`
`Petitioner’s Reply not only ignores the clear requirement that “In an inter
`
`partes review . . ., the petitioner shall have the burden of proving a proposition of
`
`unpatentability by a preponderance of the evidence” (35 U.S.C.§ 316(e)), but also
`
`fails Patent Owner’s unambiguous rebuke of Petitioner’s Grounds 1-3, as explained
`
`in detail in Patent Owner’s Response. POR, pp. 5-15.
`
`A.
`
`Petitioner’s reliance on Kirmse as disclosing “transmitting a
`request to a server to allocate a network address and port
`associated with the server to use in a data exchange session with a
`participating mobile device” remains deficient (Ground 1)
`(Independent Claims 1, 8, 15)
`
`Patent Owner’s Response explains that the Petition fails to show the above-
`
`identified limitation, as recited in the claims. POR, pp. 6-8. Petitioner’s Reply (p.
`
`1) confirms its reliance on Kirmse for the above-identified limitations (citing
`
`
`
`3
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`Petition at pp. 16 and 18-19) and asserts that Patent Owner’s Response rebutting the
`
`Petition’s assertion of Kirmse ignores that Kirmse also teaches processing requests
`
`to “start” a game. Reply, p. 2.
`
`The Petition contends, and the Institution Decision indicated, that the
`
`Petitioner had met the low threshold of institution for showing, that because Kirmse
`
`purportedly teaches to “start” a game, it teaches allocation of a session identifier.
`
`E.g., Reply, pp. 1-3. However, there is no disclosure in Kirmse that starting a game
`
`comprises allocating a session identifier, and neither Petitioner nor the Institution
`
`Decision cite to any such disclosure. In fact, in Kirmse, many games exist regardless
`
`of whether particular players are playing, and unused sessions exist to distribute to
`
`players as needed. Ex. 1005, 5:54-65. Indeed, Kirmse describes “invoking” a game
`
`numerous times throughout the specification, which denotes that the game already
`
`exists. See, e.g., Ex. 1005, 6:21-35 (describing invoking of game client).
`
`In fact, contrary to the Petitioner’s allegations in its Reply that Kirmse’s
`
`alleged disclosure of “an embodiment in which a player starts a multiplayer game”
`
`is pertinent to this recitation, e.g., Reply, p. 1, of the only four uses of the term “start”
`
`in the Kirmse Specification, only one is relevant to the portion of Kirmse relied upon
`
`in the Reply for this recitation. Kirmse, states, in relation to Kirmse Fig. 4:
`
`At step S2, the inviter's game client connects to a game server to join
`
`or start a game. In response, the game server serves up an active game
`
`
`
`4
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`(S3) and provides (S4) the inviter with enough information, such as IP
`
`address and port number, so the inviter can play the game.
`
`Kirmse, 7:32-36 (emphasis added). This clearly teaches serving of an active game
`
`in response to either joining or starting a game. The service of an active game
`
`encompasses providing the inviter with existing connection details, and providing
`
`of the inviter with the existing connection details, in contrast to the claim recitation
`
`of receiving a request to allocate a session identifier.
`
`The Petitioner hypocritically contends that Patent Owner has somehow
`
`waived the argument that starting a game does not disclose allocation of a session
`
`identifier. Reply, p. 3. However, a review of the Petitioner’s three pages of
`
`argument on pages 18-20 of the Petition clearly shows that the Petitioner does not
`
`argue that starting a game discloses allocation of a session. Not only does
`
`Petitioner fail to raise this argument in its attempt to map this claim recitation onto
`
`Kirmse on pages 18-20 of the Petition (of which 1 page is Kirmse Fig. 4, which
`
`contains no argument), Petitioner does not even use the word “start” in its entire
`
`Ground 1 Analysis section (Petition, Section VI.C., pp. 17-34). And yet Petitioner
`
`complains that Patent Owner waives the right to rebut an argument never raised in
`
`the Petition. Further, Patent Owner notes that it has asserted since the POPR that
`
`“according to the disclosure of Kirmse, “the game server serves up an active game
`
`(S3) and provides (S4) inviter with enough information, such as IP address and port
`
`
`
`5
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`number, so the inviter can play the game.” POPR, p. 9 (citing Ex. 1005, 7:33-36
`
`(emphasis added)). This argument applies whether a game is joined or started, as
`
`clearly specified in Kirmse. This hypocritical argument does not address the
`
`shortcomings of Petitioner’s evidence.
`
`Petitioner identifies no disclosure in Kirmse of allocating a session identifier
`
`as opposed to distributing an already existing identifier. Kirmse expressly states that
`
`in response to either joining or starting a game, “the game server serves up an active
`
`game (S3) and provides (S4) the inviter with enough information, such as IP address
`
`and port number.” Ex. 1005, 7:33-36. Neither Petitioner nor the Institution Decision
`
`identify where Kirmse allegedly teaches that starting a game comprises allocating a
`
`session identifier rather than serving up an active game. Extraordinarily, Petitioner
`
`attempts to repair this obvious defect in the Petition by improperly proffering a
`
`dictionary definition of “allocate” with its Reply, Ex. 1026, along with a belated
`
`Declaration relying on this dictionary definition to attempt to satisfy Petitioner’s
`
`initial burden. Ex. 1025, Para. 6. As Petitioner should readily have anticipated that a
`
`definition of a key claim term was required to make its case, the Board should not
`
`consider this belated evidence. “‘[A]fter institution, the petitioner “may not submit
`
`new evidence or argument in reply that it could have presented earlier, e.g. to make
`
`out a prima facie case of unpatentability.’ CTPG at 73.” Hulu, LLC v. Sound
`
`Innovations, Inc., IPR2018-01039, Paper No. 29 (PTAB Dec. 20, 2019)
`
`
`
`6
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`(Precedential Opinion Panel, quoting Consolidated Trial Practice Guide). Indeed,
`
`in view of this belated evidence, the Board should not consider the Petitioner’s
`
`Reply. A “reply or sur-reply that raises a new issue or belatedly presents evidence
`
`may not be considered. The Board is not required to attempt to sort proper from
`
`improper portions of the reply or sur-reply.” Consolidated Trial Practice Guide, p.
`
`74. Even if this improperly belated evidence were to be considered, Petitioner’s
`
`conclusion, based on the definition of “allocation” in Exhibit 1026, that “allocation”
`
`allegedly is synonymous with “distribution,” is only reached by completely ignoring
`
`all but a single word of the very definition Petitioner provides which states: “to
`
`apportion for a specific purpose or to particular persons or things.” Reply, p. 3
`
`(emphasis added). Further, as discussed on pages 6-8 of the POR, the Institution
`
`Decision, in its analysis on pages 13-14, only finds this recitation disclosed in
`
`Kirmse by impermissibly rewriting the claim recitation “transmitting a request to a
`
`server to allocate a network address and port associated with the server to use in a
`
`data exchange session with a participating mobile device” as a request in Kirmse to
`
`distribute “a port reference or URL string that specifies a specific game in progress.”
`
`Ex. 1005, 5:59-62. This analysis conflates Kirmse’s serving of an active game with
`
`existing connection details, and providing of the inviter with the existing connection
`
`details, with the claimed recitation of receiving a request to allocate a session
`
`
`
`7
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`identifier. Indeed, Kirmse teaches that multiple game clients, including the inviter
`
`and invitees of the inviter, may use the port reference or URL. Ex. 1005; 7:33-51.
`
`With regard to the Petitioner’s Declarant, Patent Owner noted in the POR that
`
`the Declarant mischaracterizes Kirmse by stating that the connection details include
`
`the server’s IP address and the game instance’s port number. Ex. 1002, ¶ 51, when,
`
`in fact, Kirmse states that a “specific port reference or URL string…specifies a
`
`specific game in progress.” Ex. 1005, 5:59-62. The point of the argument is to
`
`demonstrate that the Declaration is faulty because of the Declarant’s failure to
`
`accurately and completely characterize Kirmse. The Petitioner’s Expert fails to
`
`acknowledge that Kirmse may provide identification of a specific game in progress
`
`via a URL string, as opposed to a port. And further, the Petitioner’s Expert further
`
`builds on this mischaracterization by equating, with no analysis, a session identifier
`
`as a “game instance with IP address and port.” Ex. 1002, ¶ 56. The Expert again
`
`incorrectly states that a “session identifier,” referring to a game, specifically requires
`
`a port number. Ex. 1002; Para. 30. Kirmse does not use the term “session identifier,”
`
`and, far from requiring a port to access a game, allows a game to be accessed simply
`
`by a URL string.
`
`In the Reply, the Petitioner on the one hand recognizes that “Kirmse discloses
`
`that a fallback URL can also be sent in case the invitee lacks an installed local game
`
`application,” Reply pp. 4-5, but on the other hand fails to admit that this statement
`
`
`
`8
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`implicitly acknowledges that the Declarant’s statement that a session identifier
`
`requires a “game instance with IP address and port,” Ex. 1002, ¶ 59, is inaccurate.
`
`The Petitioner then doubles down on this inaccuracy, noting that the Declarant
`
`“testifies consistently” about the session identifier requiring a game instance with IP
`
`address and port. Reply, p. 5. While the Petitioner attempts to wave away this
`
`inaccuracy by stating that the “additional disclosure is not relevant,” Reply p. 5, the
`
`disclosure that a session identifier can comprise something other than a port, a URL,
`
`clearly demonstrates that the Declarant’s Declaration includes inaccuracies.
`
`Accordingly, the Petitioner’s Expert’s Declaration should be given little or no
`
`weight.
`
`Finally, Petitioner contends in the Reply that the Patent Owner has failed to
`
`explain why Kirmse does not teach the recitation of “transmitting a request to a
`
`server to allocate a network address and port associated with the server to use
`
`in a data exchange session with a participating mobile device.” Reply, pp. 1-6. As
`
`explained above, Petitioner has not shown that Kirmse teaches allocating a session
`
`identifier, or that starting a game involves allocating a session identifier. In the
`
`Institution Decision, the Board indicates that “the game client may alternatively
`
`obtain the reference to the game from the server.” Decision, p. 13. Patent Owner
`
`submits that the disclosure to “obtain” a reference implies that the reference already
`
`exists, supporting Patent Owner’s contention that Kirmse teaches serving an existing
`
`
`
`9
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`session identifier to users, rather than allocating a session identifier as required by
`
`the claim limitation. It is unclear how the Board can interpret the use of an existing
`
`reference as teaching allocation of a session identifier.
`
`Accordingly, Kirmse does not teach “transmitting a request to a server to
`
`allocate a network address and port associated with the server to use in a data
`
`exchange session with a participating mobile device” as required by the claim
`
`language, and thus Ground 1 fails.
`
`B.
`
`Petitioner’s reliance on the combination of Chambers and RSIP
`as disclosing “transmitting a request to a server to allocate a
`network address and port associated with the server to use in a
`data exchange session with a participating mobile device” remains
`deficient (Ground 2) (Independent Claims 1, 8, 15)
`
`Patent Owner’s Response explains that the Petition fails to show the above-
`
`identified limitations, as recited in the claims. POR, pp. 8-13. Petitioner’s Reply
`
`(pp. 6-11) confirms its reliance on Chambers and RSIP for the above-identified
`
`limitations and asserts that Patent Owner’s Response fails to take into account “RSIP
`
`as a whole.” Reply, p. 9. The Petitioner has the burden of proof. 35 U.S.C. § 316(e)
`
`(“the petitioner shall have the burden of proving a proposition of unpatentability by
`
`a preponderance of the evidence”). Here, in the Reply, rather than respond to the
`
`POR, Petitioner has improperly proceeded in a new direction with a new approach
`
`compared to the Petition, by citing to different portions of RSIP to purportedly
`
`explain why its original citations actually teach what Petitioner said they teach,
`
`
`
`10
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`because it is not clear from the original citations themselves that they teach what
`
`Petitioner contends they teach. ““Respond,” in the context of 37 C.F.R. § 42.23(b),
`
`does not mean proceed in a new direction with a new approach as compared to the
`
`positions taken in a prior filing.” Consolidated Trial Practice Guide, p. 74.
`
`Accordingly, for this additional reason, the Board should not consider the
`
`Petitioner’s Reply. And yet, even with these new citations to “RSIP as a whole,”
`
`RSIP does not teach what the Petitioner is contending it teaches.
`
`In fact, neither Chambers nor RSIP teaches or suggests the required
`
`transmitting, to a server, a request to allocate a network address and port associated
`
`with the server. While the Petitioner contends that such a teaching exists when
`
`considering the “RSIP as a whole,” Reply, p. 9, as noted above, this is essentially an
`
`admission that the original citations do not clearly teach this recitation. As disclosed
`
`in RSIP, the system comprises three different devices: an RSIP Host, an RSIP
`
`Gateway, and a Host:
`
`
`
`
`
`11
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`A POSITA would understand that when a reference is discussing ports in
`
`relation to a plurality of devices, the term “local” must be construed in relation to
`
`the particular device that is being discussed.
`
`As discussed in the POR, RSIP does not disclose the required allocating of a
`
`network address and port associated with the server. As discussed in detail in the
`
`Preliminary Response at pages 12-17,
`
`the description of
`
`the
`
`related
`
`ASSIGN_REQUEST_RSAP-IP
`
`message
`
`indicates
`
`that
`
`for
`
`the
`
`“ASSIGN_REQUEST_RSAP-IP” message, “The RSIP host specifies two address
`
`and two port parameters: a local address and port (, which refers to an address and
`
`port for the RSIP Host, and second remote address and port(s) that will be contacted:
`
`
`
`Ex. 10131 at p. 27 (highlighting and underlining added).
`
`Further still, the Petition itself argues that RSIP should be used “with the no
`
`remote flow policy”. Pet. 40; see also Pet. 37, 41, 42, 47. And regarding “remote
`
`flow policy”, RSIP expressly states that under a “no flow” policy, the hosts (a.k.a.
`
`
`1 The page numbers refer to the page numbers added by Petitioner at the bottom
`right of Ex. 1013.
`
`
`
`12
`
`
`
`mobile devices) communicate without explicitly notifying the gateway (a.k.a. the
`
`server):
`
`IPR2019-00701
`Patent 8,018,877
`
`
`
`Ex. 1013 at p. 13 (highlighting and underlining added). The foregoing further
`
`confirms that under RSIP the allocation of “addressing parameters” is “to the host”
`
`(a.k.a. the mobile device), and not associated with the RSIP gateway (a.k.a. the
`
`server), as required by the claim language.
`
`In an effort to evade the lack of support for Petitioner’s position in any specific
`
`portion of RSIP, the Reply goes into a lengthy discussion of what the “RSIP as a
`
`whole” allegedly teaches. Reply, pp. 9-11. However, the discussion of what other
`
`parts of the RSIP teach does not change that the actual disclosures Petitioner cites to
`
`in support of the element of transmitting a request to a server to allocate a network
`
`address and port associated with the server rely on interpreting the term “local” in
`
`RSIP contrary to its clear meaning. Patent Owner submits that one of ordinary skill,
`
`when faced with a system comprising three devices, would understand from RSIP’s
`
`statement that “The RSIP host specifies . . . the local address and port(s) that will be
`
`used,” that the term “local” refers to the ports of the RSIP host, if the term “local”
`
`is to have any meaning. If the local address and port(s) were intended to refer to the
`
`
`
`13
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`address and ports of the RSIP Gateway, then reference to the “RSIP Gateway”
`
`addresses and ports could easily have been specified. Neither the description for the
`
`ASSIGN_RESPONSE_RSAP-IP
`
`nor
`
`the
`
`description
`
`for
`
`the
`
`ASSIGN_REQUEST_RSAP-IP teach allocation of a network port of the RSIP
`
`Gateway. The improper supplemental Declaration submitted by Petitioner, while
`
`mentioning these ASSIGN requests, fails to so state. Ex. 1025, Para. 8. Likewise,
`
`as also discussed in the POR (POR, pp. 11-13), there is nothing in the description
`
`for the LISTEN_REQUEST regarding a request to allocate a network address and
`
`port associated with the RSIP Gateway (a.k.a. the server). While the belated
`
`supplemental Declaration of Petitioner’s expert purports to address this issue, the
`
`Declaration merely parrots the Response (Ex. 1025, Para. 7-8; Reply, pp. 9-11), and
`
`fails
`
`to address
`
`the fact
`
`that RSIP does not state
`
`that
`
`the message
`
`ASSIGN_RESPONSE_RSAP-IP allocates network ports of the RSIP Gateway, but
`
`merely characterizes the message as communicating: “a bind ID of 1 has been
`
`assigned to IP address 149.112.240.156 with ports 1234-1237,” Ex. 1013, 50, with
`
`no indication that those ports are anything other than ports of the host.
`
`It is the Petitioner’s burden to show that the prior art teaches what it is
`
`purported to teach. 35 U.S.C. § 316(e)) (“the petitioner shall have the burden of
`
`proving a proposition of unpatentability by a preponderance of the evidence”).
`
`Petitioner tries to shift its burden by claiming that Patent Owner has not shown that
`
`
`
`14
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`local address and port means “something different than it does everywhere else in
`
`RSIP.” Reply, 10. However, Petitioner has the burden to substantiate the contention
`
`that “local” refers to ports of the RSIP Gateway “everywhere else” in RSIP, which
`
`it has not met. A POSITA would understand that “local” used in RSIP refers to the
`
`particular device being discussed. Here, the Petitioner, faced with a clear deficiency
`
`in its arguments for unpatentability, attempts to impose on the term “local” the
`
`condition that “local” means “local,” not to the particular device under discussion,
`
`but to the RSIP Gateway, even though the system includes at least three different
`
`devices: the RSIP host, the RSIP Gateway, and the host. If the authors of RSIP had
`
`intended that “local” should be understood as always referring to the RSIP Gateway,
`
`the clear term “RSIP Gateway” could have easily been used rather than the relative
`
`term “local.” Petitioner’s incredulity that the term “local” can refer to different
`
`devices, in a system that comprises at least three different devices, does not provide
`
`support for its interpretation.
`
`Further, as noted in the POR, the Institution Decision relies on the deficient
`
`showing by the Petitioner, which the Petitioner does not remedy in the Reply. POR,
`
`pp. 9-10. The statement that the RSIP gateway (i.e., the RSIP server) should control
`
`its own local addresses and ports is only that, a teaching that a server can control its
`
`own addresses and ports. POR, p. 9. It is in no way a teaching that the RSIP server
`
`allocates a session identifier comprising the local (RSIP server) addresses and ports
`
`
`
`15
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`and sends the session identifier to other devices. Further, the statement “to deliver
`
`parameter assignments” does not specify whether the parameters refer to server ports
`
`or local ports of the mobile devices. POR, pp. 11-12. Petitioner does not even
`
`attempt to address this contention relating to the parameter assignments.
`
`Thus, the citations relied upon by the Institution Decision do not teach that
`
`the session identifier comprises a network port associated with the RSIP server.
`
`Therefore, the combination of Chambers and RSIP does not teach the recitation of
`
`transmitting a request to a server to allocate a network address and port associated
`
`with the server.
`
`
`
`C.
`
`Petitioner’s assertion that a POSITA Would Have Combined
`Cordenier and TURN remains deficient (Ground 3)
`
`Patent Owner’s Response explains that the Petition fails to carry the burden
`
`that a POSITA would have combined Cordenier and TURN. POR, 13-16.
`
`Petitioner’s Reply, pp. 12-15, confirms its reliance on the combination of Cordenier
`
`and TURN (citing Paper 1 at pp. 11-14; pp. 46-49) and asserts that Patent Owner’s
`
`Response rebutting
`
`the Petition’s assertion of Cordenier and TURN
`
`is
`
`“fundamentally flawed.” Reply, p. 12.
`
`However, Petitioner’s arguments are based upon a convoluted argument that
`
`essentially contends that because a “relay server” and an “exchange server” are not
`
`
`
`16
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`identical, it would have been obvious to combine Cordenier and TURN, even though
`
`a relay server would impose the same type of limitations as an exchange server on
`
`the Cordenier system that Cordenier is designed to overcome.
`
`The Background section of Cordenier explains that in existing systems “the
`
`system requires both parties to be connected to the internet and to have an IP address
`
`assigned before a peer-to-peer communication channel can be established between
`
`both parties. Ex. 1007, ¶ 4. Cordenier further explains that “To be able to exchange
`
`the IP-addresses of users, it is always necessary that both users are online to the
`
`Internet and that both users are registered at the same IP-exchange server.” Ex.
`
`1007, ¶ 5. Thus, in Cordenier, “It is an object of the invention to provide an
`
`architecture for peer-to-peer communication between a first and second terminal
`
`using a data network, but without the need for a common exchange server in the
`
`data network.” Id. ¶ 6 (emphasis added).
`
`Regardless of whether TURN is considered to teach an exchange server or a
`
`relay server, there is no doubt that it teaches a server (TURN Server) that acts as an
`
`intermediary between different peers, to facilitate transmissions between the peers.
`
`TURN, p. 6. To facilitate transmissions, the TURN Client has to discover the
`
`address of the TURN Server. TURN, p. 8. Then the TURN Client has to send a
`
`TURN allocate request to the TURN Server. Id. This intermediary interaction
`
`
`
`17
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`required by TURN is precisely the type of intermediary interaction that Cordenier
`
`is designed to avoid.
`
`The Petitioner attempts to distinguish the TURN Server by arguing that
`
`because a user may request a public IP address, and then transmit that address to a
`
`recipient using a different application, such that when the recipient sends a message
`
`using the IP address, the “TURN server will then transparently relay that response
`
`to the initiating user.” Reply, p. 13 (citing Petition, pp. 69-71). Even assuming
`
`arguendo this is true, this neither negates that coordination and initial allocation with
`
`the TURN server is necessary for the communication, and does not negate that the
`
`TURN server must act as an intermediary, even if the TURN server is purportedly
`
`“transparent.”
`
`As noted in the POR, p. 13, the incorporation of TURN, which provides a
`
`relay server to forward communications between the terminals (Ex. 1002; Par. 66;
`
`Ex. 1009; 4), is directly contrary to the goal of Cordenier to “provide an architecture
`
`for peer-to-peer communication between a first and a second terminal using a data
`
`network, but without the need of a common exchange server in the data network.”
`
`Ex. 1007; ¶ 6. As TURN requires a TURN server, a POSITA, seeking to modify
`
`Cordenier’s peer-to-peer communication approach without an exchange server,
`
`would not incorporate TURN. Notably, Petitioner’s Declarant, even with a belated
`
`
`
`18
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`and improper second Declaration, does not attempt to address this clear statement in
`
`Cordenier. Ex. 1025.
`
`Further, the Petitioner’s contention that the system required by TURN, which
`
`requires both a TURN Server and TURN Client (TURN, p. 7), is analogous to a
`
`network address translator is untenable. As shown in TURN Fig. 1 (TURN, p. 7), a
`
`network address translator, or NAT, is a completely different device and performs a
`
`separate function than a TURN Server or TURN Client:
`
`TURN, p. 7. If a NAT is analogous to a TURN, the TURN Server and TURN Client
`
`shown in TURN Fig. 1 would not be necessary in a TURN system. In fact, a NAT
`
`
`
`
`
`19
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`is a device that translates an address without any requirement that it is first
`
`configured or initiated by a user, unlike a TURN Server, which requires the TURN
`
`Client to discover the TURN Server and then requires the TURN client to send an
`
`allocation request to the TURN Server. TURN, p. 8. The belated supplemental
`
`Declaration supplied by Petitioner, while touching on the use of a network address
`
`translator, Ex. 1025, Para. 11, utterly fails to address this point, and thus should be
`
`given no weight. Thus, there is no support for the contention that a network address
`
`translator is at all similar to a TURN system comprising a TURN Server and a TURN
`
`client.
`
`As noted in the POR, p. 13, Petitioner’s Declarant fails to address the
`
`fundamental incompatibility between the goal of Cordenier of providing a peer-to-
`
`peer network without a server, and TURN’s provision of a server. Indeed,
`
`Petitioner’s Declarant, in summarizing Cordenier, describes Cordenier as disclosing
`
`“a method for initiating an IP-based data exchange session…between mobile
`
`devices” Ex. 1002, ¶ 115, without mentioning that the object of Cordenier is to avoid
`
`“the need of a common exchange server.” Ex. 1007, ¶ 6. The Petitioner’s response
`
`to this contention in the Reply is to contend that “a POSITA would have understood
`
`that a private IP address from one side of a NAT that is sent via SMS to a recipient
`
`on the other side of a NAT would have been useless to the recipient.” Reply, p. 14.
`
`However, this argument does not address Patent Owner’s contentions concerning
`
`
`
`20
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`the fundamental incompatibility between Cordenier and TURN. This is simply an
`
`argument to combine the references to read on the claims, regardless of the
`
`compatibility of the references.
`
`As previously noted, the Board’s decision states that “Petitioner relies on
`
`TURN for its teaching of allocating a session identifier (IP address and port number)
`
`using a TURN server to use in a data exchange session.” Paper No. 7, p. 26. The
`
`allocating of IP addresses to every device is exactly contrary to Cordenier, which
`
`seeks to avoid the requirement that “it is always necessary that both users are online
`
`to the Internet and that both users are registered at the same IP-exchange server.”
`
`Ex. 1007, ¶ 5.
`
`Thus, Petitioner has not established a motivation to combine Cordenier and
`
`TURN. Petitioner’s attempts to analogize a TURN to a NAT are incorrect, as are
`
`Petitioner’s attempts to distinguish a relay from an exchange server, when both
`
`require initiation and allocation steps that the Cordenier system teaches away from.
`
`The Petition merely offers hindsight reconstruction, under which one of ordinary
`
`skill familiar with Cordenier would combine it with NAT solely to provide the
`
`functionality recited in the ‘877 claims.
`
`Thus, because the combination of TURN with Cordenier is based upon
`
`impermissible hindsight analysis, Ground 3 fails.
`
`
`
`21
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`III. APJS ARE UNCONSTITUTIONALLY APPOINTED PRINCIPAL
`OFFICERS
`
`As discussed in detail in the POR, (POR, pp. 17-18), Patent Owner submits
`
`that APJs are principal officers under the Appointments Clause of the Constitution.
`
`IV. CONCLUSION
`
`For at least the reasons set forth above, Uniloc respectfully requests that the
`
`Board deny all challenges in the instant Petition.2
`
`
`
`
`
`Date: March 23, 2020
`
`
`
`
`
`Respectfully submitted,
`
`By:/Ryan Loveless/
`Ryan Loveless
`Reg. No. 51,970
`Brett A. Mangrum
`Reg. No. 64,783
`Attorneys for Patent Owner
`
`
`
`
`
`
`2 Patent Owner does not concede, and specifically denies, that there is any
`
`legitimacy to any arguments in the instant Petition that are not specifically
`
`addressed herein.
`
`
`
`
`
`22
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`CERTIFICATE OF COMPLIANCE
`
`Pursuant to 37 C.F.R. § 42.24(d), the undersigned certifies that the foregoing
`
`complies with the type-volume limitation of 37 C.F.R. § 42.24(c)(1) because it
`
`contains fewer than the limit of 5,600 words, as determined by the word- processing
`
`program used to prepare the brief, excluding the parts of the brief exempted by 37
`
`C.F.R. § 42.24(c).
`
`Date: March 24, 2020
`
`
`
`
`
`Respectfully submitted,
`
`By: /Ryan Loveless/
`Ryan Loveless
`Reg. No. 51,970
`Brett A. Mangrum
`Reg. No. 64,783
`Attorneys for Patent Owner
`
`
`
`23
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. §§ 42.6(e), the undersigned certifies that an electronic
`
`copy of the foregoing Sur Reply was served via email to Petitioner’s counsel at the
`
`following addresses identified in the Petition’s consent to electronic service:
`
`Brian Erickson (Reg. No. 48,895)
`James M. Heintz (Reg. No. 41,828)
`brian.erickson@dlapiper.com
`jim.heintz@dlapiper.com
`
`
`Date: March 24, 2020
`
`
`
`
`
`Respectfully submitted,
`
`By: /Ryan Loveless/
`Ryan Loveless
`Reg. No. 51,970
`Brett A. Mangrum
`Reg. No. 64,783
`Attorneys for Patent Owner
`
`
`
`
`
`24
`
`
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
