UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner
`
`U.S. Patent No. 8,018,877
`
`Inter Partes Review No.: IPR2019-00701
`
`PETITIONER’S REPLY TO PATENT
`OWNER’S RESPONSE TO PETITION
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`WEST/288875011
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner
`
`U.S. Patent No. 8,018,877
`
`Inter Partes Review No.: IPR2019-00701
`
`PETITIONER’S REPLY TO PATENT
`OWNER’S RESPONSE TO PETITION
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`WEST/288875011
`
`
`
`Table of Contents
`
`Page
`
`I.
`II.
`
`Introduction ..................................................................................................... 1
`The Challenged Claims are Unpatentable ...................................................... 1
`A. Ground 1: Claims 1-20 are Unpatentable Over the
`Combination of Kirmse (Ex. 1005) and Chambers (Ex. 1006) ........... 1
`B. Ground 2: Claims 1-20 are Unpatentable Over the
`Combination of Chambers (Ex. 1006) and RSIP (EX. 1007) .............. 6
`C. Ground 3: Claims 1-3, 5-10, 12-17, and 19-20 are
`Unpatentable Over Cordenier (Ex. 1007) and TURN (Ex. 1009) ..... 12
`III. The Dependent Claims are Unpatentable ..................................................... 15
`IV. APJs are Not Unconsitutionally Appointed Principal Officers .................... 15
`V.
`Conclusion .................................................................................................... 16
`
`WEST/288875011
`
`i
`
`
`
`Exhibits
`
`1009
`
`1010
`
`1011
`1012
`1013
`
`Exhibit No. Description
`1001
`U.S. Patent No. 8,018,877 to Lin
`1002
`Declaration of Dr. Henry Houh
`1003
`File History of U.S. Pat. No. 8,018,877 to Lin
`1004
`File History of U.S. Pat. No. 7,961,663 to Lin
`U.S. Pat. No. 6,699,125 (“Kirmse”)
`1005
`U.S. Pat. App. Pub. No. US 2003/0142654 (“Chambers”)
`1006
`European Pat. App. Pub. EP 1 385 323 A1 (“Cordenier”)
`1007
`1008
`Complaint for Patent Infringement dated February 22, 2018
`(“Uniloc Complaint”)
`Declaration by Alexa Morris with the exhibit “draft-rosenberg-
`midcom-turn-00.txt”, Traversal Using Relay NAT (“TURN”)
`Declaration of Sandy Ginoza for IETF RFC 793: Transmission
`Control Protocol with the exhibit, RFC 793, “Transmission Control
`Protocol” (“RFC793”)
`U.S. Pat. App. Pub. No. 2003/0217174 (“Dorenbosch”)
`U.S. Patent No. 7,961,663 to Lin (“663 Patent”)
`Declaration of Sandy Ginoza for IETF RFC 3103: Realm Specific
`IP: Protocol Specification with exhibit, RFC 3103, “Realm
`Specific IP: Protocol Specification” (“RSIP”)
`Certified Translation and Original of European Pat. App. Pub. EP 1
`009 153 A1 (“Alos”)
`Declaration by Alexa Morris with the exhibit “draft-rosenberg-
`sipping-ice-00.txt,” Interactive Connectivity Establishment (ICE): A
`Methodology for Network Address Translator (NAT) Traversal for
`the Session Initiation Protocol (SIP) (“ICE”)
`U.S. Patent No. 7,969,925 to Lin (“925 Patent”)
`Declaration of Sandy Ginoza for IETF RFC 1918: Address
`Allocation for Private Internets with exhibit, RFC 1918, “Address
`Allocation for Private Internets” (“NAT”)
`
`1014
`
`1015
`
`1016
`1017
`
`WEST/288875011
`
`i
`
`
`
`Exhibits continued
`
`Exhibit No. Description
`U.S. Patent No. 8,539,552 (“Grabelsky”)
`1018
`1019
`Declaration of Sandy Ginoza for IETF RFC 3489: STUN - Simple
`Traversal of User Datagram Protocol (UDP) Through Network
`Address Translators (NATs) with the exhibit, RFC 3489, “STUN -
`Simple Traversal of User Datagram Protocol (UDP) Through
`Network Address Translators (NATs)” (“STUN”)
`January 3, 2011 Amendment and Response to Office Action from
`file history of U.S. Pat. No. 7,969,925 to Lin
`U.S. Pat. App. No. 10/817,994 to Lin
`U.S. Pat. App. No. 10/935,342 to Lin
`U.S. Pat. App. No. 11/042,620 to Lin
`Declaration of Sandy Ginoza for IETF RFC 2026: The Internet
`Standards Process – Revision 3 with the exhibit, RFC 2026: “The
`Internet Standards Process – Revision 3” (“Internet Standards
`Process”)
`Declaration of Dr. Henry H. Houh In Support of Petitioner’s Reply
`to Patent Owner’s Response to Petition
`Merriam-Webster’s Collegiate Dictionary, 10th Ed., (2002)
`definition of “allocate”
`
`1020
`
`1021
`1022
`1023
`1024
`
`1025
`
`1026
`
`WEST/288875011
`
`ii
`
`
`
`I.
`
`INTRODUCTION
`Patent Owner’s (“PO’s”) Response, Paper 9, (the “POR”) primarily rehashes
`
`arguments from PO’s Preliminary Response that the Board already considered and
`
`correctly rejected in its Institution Decision. PO does not explain or clarify its
`
`arguments in response to the Board’s feedback that they were unclear, or support
`
`them with the testimony of any expert to address the Board’s feedback that they
`
`were unpersuasive. PO’s arguments should be rejected again for the reasons set
`
`forth in the Board’s Institution Decision and for the reasons set forth below.
`
`II.
`
`THE CHALLENGED CLAIMS ARE UNPATENTABLE
`A.
`Ground 1: Claims 1-20 are Unpatentable Over the Combination
`of Kirmse (Ex. 1005) and Chambers (Ex. 1006)
`The only dispute PO raises with respect to Ground 1 is that Kirmse fails to
`
`disclose “transmitting a request to a server to allocate a network address and port
`
`associated with the server” (the “allocating limitation”) because Kirmse only
`
`discloses requests to join pre-existing games. POR at 6-8. This argument fails for
`
`at least two reasons. First, PO fails to respond to the showing in the Petition and
`
`Institution Decision that Kirmse discloses requests to start a game, waiving any
`
`such response. Second, Kirmse’s disclosure of requests to join a game clearly
`
`satisfies the ordinary meaning of the allocating limitation.
`
`As established in the Petition, Kirmse discloses an embodiment in which a
`
`player starts a multiplayer game.
`
`WEST/288875011
`
`1
`
`
`
`At step S2, the inviter’s game client connects to a game
`server to join or start a game.
`
`Ex. 1005, Fig. 4, 7:31-32 (emphasis added); Petition, 16 (“a player starts a
`
`multiplayer game instance”), 18-19. “In response” to that request, the game server
`
`“serves up an active game” and provides the requestor with the address and port
`
`number so the requestor can play the game.
`
`In response, the game server serves up an active game
`(S3) and provides (S4) the inviter with enough
`information, such as IP address and port number, so the
`inviter can play the game.
`
`Ex. 1005, Fig. 4, 7:33-36; Petition, 18-19. Thus, Kirmse discloses the game server
`
`“in response” to a request to start a game “serves up” a game. Once the new game
`
`is “active,” the server provides the IP address and port number in response (S4).
`
`The Board in its Institution Decision also repeatedly discusses Kirmse’s disclosure
`
`of starting a game. Paper No. 7 at 9 (“[i]n one embodiment, a player starts a
`
`multiplayer game S1.”), 13 (“For instance, once the game client connects to the
`
`game server to join or start a game (S2), the game server serves up an active game
`
`(S3) and provides (S4) the inviter with information such as an IP address and port
`
`number, so the inviter can play the game.”) (emphasis added).
`
`Despite the clear notice in both the Petition and the Institution Decision that
`
`Kirmse discloses requests to start a game, PO focuses solely on requests to “join
`
`WEST/288875011
`
`2
`
`
`
`and play an already-active game” with “existing connection details.” POR at 6-8.
`
`PO fails to discuss Kirmse’s disclosure of requests to start a game and provide the
`
`connection information for that new game. Id. The Scheduling Order warns PO
`
`“that any arguments not raised in the response may be deemed waived.” Paper No.
`
`8 at 7. Here, by failing to address this issue in its Response, PO has waived any
`
`argument that Kirmse’s disclosure of requests to start games does not disclose the
`
`allocating limitation. In light of PO’s failure to contest any other issue for Ground
`
`1 in its Response, the Board should find that Petition has proven the
`
`unpatentability of all Challenged Claims on the basis of Ground 1 for this reason
`
`alone.
`
`Regardless, PO’s attempt to distinguish Kirmse’s request to join and play an
`
`existing game fails under the ordinary meaning of the allocating limitation. Ex.
`
`1005, Fig. 4, 7:33-36; Petition, 18-19. PO repeatedly states that Kirmse’s request
`
`to join an existing game is not sufficient (POR, 6-8), but PO never explains its
`
`argument, completely ignoring the Board’s feedback. Paper 7 (Decision) at 13.
`
`PO does not seek a narrowing construction of “allocate,” and fails to explain how a
`
`request to distribute connection details to join an existing game does not satisfy the
`
`ordinary meaning, which includes “to apportion for a specific purpose or to
`
`particular persons or things : DISTRIBUTE.” Petition at 19; Ex. 1026, 3; Ex.
`
`1001, 4:62-66, 5:15-20. Additionally, Kirmse discloses that the game server can
`
`WEST/288875011
`
`3
`
`
`
`include many active games. Ex. 1005, Fig. 1 (illustrating two games), 5:54-67
`
`(disclosing support for many simultaneous games); Petition, 18-19. The server
`
`choosing a game and then distributing the connection details for the chosen game
`
`also satisfies the ordinary meaning of “allocate.” Ex. 1025, ¶6.
`
`PO’s remaining arguments in the POR at 7-8 do not address the deficiencies
`
`noted above. PO points to Kirmse’s disclosure that multiple game clients may use
`
`the same port reference (POR, 7 (citing Ex. 1005, 7:33-51)), but PO cannot
`
`distinguish Kirmse from the claims on this basis. The challenged patent contains a
`
`substantially identical disclosure wherein multiple devices use the same port
`
`number for multiplayer gaming. Ex. 1001, 5:15-35 (disclosing that multiple
`
`devices may each invite additional devices to join using the same port number), 8:9
`
`(multiplayer gaming). Indeed, dependent claims 4, 11, and 18 require that
`
`additional devices join the session, and PO does not dispute that this aspect of
`
`Kirmse discloses the limitations added by those dependent claims. Petition, 32-33;
`
`Ex. 1001, 8:45-46 (claim 4), 8:16-18 (claim 11), 10:23-24 (claim 18) (each
`
`claiming “wherein additional devices are invited to participate in the data exchange
`
`session.”)
`
`PO then points out that Dr. Houh’s overview of Kirmse does not address
`
`Kirmse’s additional disclosures related to URLs. POR, 7. It is true that Kirmse
`
`discloses that a fallback URL can also be sent in case the invitee lacks an installed
`
`WEST/288875011
`
`4
`
`
`
`local game application. Ex. 1005, Fig. 5 (“Faltback [sic] URL =
`
`‘…/nogameinstalled.html’”), 5:59-60, 9:11-15. That additional disclosure is not
`
`relevant to Kirmse’s disclosure of the relevant IP address and port number. Id.,
`
`Fig. 5 (IP address “192.168.0.17” and port number “28001”). Dr. Houh accurately
`
`testifies in paragraph 51 of his declaration that Kirmse discloses that the
`
`connection details include the server’s IP address and the game instance’s port
`
`number. Ex. 1002, ¶51 (citing support in Kirmse, including Figures 4-5 and 7:35
`
`(“IP address and port number”)). Dr. Houh testifies consistently in paragraphs 56-
`
`57 of his declaration where he specifically addresses this limitation, including
`
`additional citations to Kirmse. Ex. 1002, ¶¶56-57 (citing numerous disclosures of
`
`the allocated IP addresses and port numbers). Thus, PO’s critique of Dr. Houh’s
`
`testimony is unfounded.
`
`PO then argues that Kirmse does not disclose the claimed request to allocate
`
`because Kirmse also discloses that the game client may already know the
`
`information. POR, 7. But as the Board correctly pointed out in its Decision (Paper
`
`7, 13), the same passage also teaches that the game client may obtain the reference
`
`to the game from the server, which is consistent with the disclosures in Kirmse
`
`relied on for Ground 1. Ex. 1005, 5:59-65.
`
`PO then asserts that Dr. Houh only addresses the claim terms in the context
`
`of the claims, and fails to address the claim terms in the context of his overview.
`
`WEST/288875011
`
`5
`
`
`
`POR, 7-8. This critique of Dr. Houh is also unfounded, as there is no reason for
`
`Dr. Houh to address all of the claim terms in his overview of a reference.
`
` PO then concludes by repeating its argument that a request to join an
`
`already-active game is not a request to allocate. POR, 8. That argument is
`
`meritless as established above.
`
`Finally, it should be noted that PO raised this argument in its preliminary
`
`response (Paper 6 (POPR) at 8-10), and the Board noted in its Institution Decision
`
`that PO failed to explain its argument. Paper 7 (Decision) at 13 (“Moreover,
`
`Patent Owner does not explain why . . . . Patent Owner does not explain in any
`
`way why . . . .”). Despite being provided that feedback by the Board, PO again
`
`fails to explain why Kirmse purportedly fails to disclose this limitation. PO fails to
`
`offer a narrow construction that would distinguish requests to join existing games,
`
`fails to address requests to start games, and fails to provide any expert testimony to
`
`support or clarify its argument. Thus, PO’s attorney argument is still unpersuasive
`
`for the reasons noted by the Board in its Institution Decision.
`
`B.
`
`Ground 2: Claims 1-20 are Unpatentable Over the Combination
`of Chambers (Ex. 1006) and RSIP (EX. 1007)
`PO only disputes whether the combination of Chambers and RSIP discloses
`
`“transmitting a request to a server to allocate a network address and port
`
`associated with the server.” POR at 8-13 (emphasis in original). The Board
`
`correctly rejected this argument in its Institution Decision. Paper No. 7 at 18.
`
`WEST/288875011
`
`6
`
`
`
`PO’s argument fails because, as established in the Petition, the addresses and ports
`
`requested by the host and allocated by the RSIP Server are the public IP addresses
`
`and ports associated with the RSIP Server.
`
`The RSIP architecture is set forth at length in the Petition and Dr. Houh’s
`
`declaration, and its relevant aspects are correctly set forth by the Board in its
`
`Institution Decision. Petition, 34-35, 39-48; Ex. 1002, ¶¶77-78, 86-105; Decision,
`
`16-18. In short, host X is in a first, private address space A and has a private IP
`
`address. Ex. 1013 (RSIP), 8-9; Ex. 1017 (RFC1918), 8; Petition, 13, 34-35; Ex.
`
`1002, ¶¶45, 77-78. The RSIP Server bridges the first, private address space A with
`
`interface Na, and a second, public address space B with interface Nb. Id. The
`
`RSIP Server has a pool of public IP addresses “which it can assign to or lend to X
`
`and other hosts.” Ex. 1013, 10 (e.g., Nb1, Nb2, Nb3). In response to a request by
`
`host X, the RSIP Server allocates, assigns, and leases public IP addresses and ports
`
`in address space B for use by the host X to communicate with device Y. Host X
`
`then tunnels messages through the RSIP Server to device Y, for example, using a
`
`first header X to Na, then the RSIP Server strips that header and forwards the
`
`message to device Y using the header Nb to Y. Ex. 1013, 10-12, Petition, 43-45,
`
`Ex. 1002, ¶¶96-98. The RSIP Server receives responses from device Y at the
`
`allocated public IP address and port and forwards them to host X. Id. Importantly,
`
`PO does not contest that the Petition establishes for claim limitations 1.d, 8.d, and
`
`WEST/288875011
`
`7
`
`
`
`15.d that the RSIP Server participates in the subsequent data exchange by receiving
`
`inbound packets from device Y at the allocated public IP address and port, and
`
`then forwarding those packets to the host. Petition, 43-45; Ex. 1002, ¶¶96-98. PO
`
`does not attempt to offer, much less substantiate, a contrary interpretation of the
`
`architecture disclosed by RSIP.
`
`RSIP refers to the requesting host X’s address as a private IP address in the
`
`private realm. Ex. 1013, 8-10; Petition, 40-41; Ex. 1002, ¶¶88-92. RSIP refers to
`
`the public IP address and ports owned and controlled by the RSIP Server (which it
`
`allocates, assigns, and leases to the host) as the “local” address and ports, the
`
`“local” parameters, or a “Resource.” Id. RSIP refers to the remote device’s IP
`
`address and port as the “remote” address and ports. Id. The host “must” use the
`
`local address and the port (micro-flow) or ports (macro-flow) allocated by the
`
`RSIP Server. Ex. 1013, 13 (explaining “Local Flow Policy”).
`
`PO acknowledges that RSIP discloses that the RSIP Server controls “which
`
`local addresses and ports are used to communicate with remote addresses and
`
`ports.” POR, 10 (citing Ex. 1013, 12). And PO admits that the “local address and
`
`ports” referred to in this passage of RSIP are the RSIP Server’s “own local
`
`addresses and ports.” Id.
`
`PO argues very narrowly that, when RSIP again refers to the “local address
`
`and ports” in the description of the Assign and Listen requests and responses, RSIP
`
`WEST/288875011
`
`8
`
`
`
`does not explicitly repeat its teaching that those are the RSIP Server’s local
`
`addresses and ports. POR, 11-12. PO asserts that the reference to “local address
`
`and ports” here refers to “the [sic] local to the requesting mobile device.” POR,
`
`11 (emphasis in original), 12 (making similar argument). PO does not explain
`
`what PO means by “local to the requesting mobile device,” or provide any basis for
`
`its argument that RSIP would use “local address and ports” differently here than
`
`everywhere else. PO then states that, in isolation, the descriptions of the
`
`requests/responses do not explicitly teach that the “local address and port” are
`
`associated with the RSIP Server. Id.
`
`PO’s argument is fundamentally flawed because it attacks the description of
`
`the requests/responses in isolation, without considering RSIP as a whole. As
`
`established above, PO admits that RSIP uses “local address and port” to refer to the
`
`RSIP Server’s own addresses and ports. POR, 10. PO admits there are only two
`
`addresses/port combinations in the requests and responses, and admits that the
`
`“remote” one pertains to the remote device. POR, 10-11. PO provides no basis,
`
`and there is none, for its assertion that “local address and port” in these passages
`
`means something different than it does everywhere else in RSIP. A POSITA
`
`would have understood that “local address and ports” in these passages of RSIP is
`
`consistent with the rest of RSIP, and refers to the RSIP Server’s public address and
`
`ports. Moreover, a POSITA would have known that, as the only other address and
`
`WEST/288875011
`
`9
`
`
`
`port discussed in the protocol, the local address and port must be the public IP
`
`address and port of the RSIP Server. Ex. 1025, ¶7.
`
`Additionally, the example provided in RSIP and relied on in the Petition
`
`conclusively establishes that the “local address and ports” referred to in description
`
`of the requests and responses are the public IP address and ports of the RSIP
`
`Server. Petition, 40-42, 48 (citing Ex. 1013 at 49-51); Ex. 1002, ¶¶87-92, 105. In
`
`that example, there are two ASSIGN requests and responses. In the first request,
`
`ASSIGN_REQUEST_RSAP-IP, the host specifies “Address (local) = 0, Ports
`
`(local) = 4-0,” because the host wants four ports but does not care what public IP
`
`address is allocated. Ex. 1013, 50. The RSIP Server then allocates one of its
`
`public IP addresses, 149.112.240.156, and the four ports 1234-1237, and returns
`
`them in the response, ASSIGN_RESPONSE_RSAP-IP. Ex. 1013, 8 (defining
`
`private addresses), 50 (allocating 149.112.240.156, a public IP address). In the
`
`second request, the host wants the RSIP Server to allocate eight more ports using
`
`the same public IP address and, therefore, specifies in the second request “Address
`
`(local) = 149.112.240.156, Ports (local) = 8-1238.” Ex. 1013, 50-51. The RSIP
`
`Server then allocates eight more ports at the same public IP address
`
`149.112.240.156 and provides them to the host in the second response. Id., 51.
`
`The public IP address 149.112.240.156 is not a private address of the host. Ex.
`
`WEST/288875011
`
`10
`
`
`
`1013, 8 (defining the private addresses in the host’s private address realm); Ex.
`
`1025, ¶8.
`
`Contrary to PO’s assertion in the POR at 12-13, the remote flow policies
`
`disclosed in RSIP confirm that the allocated address and port are associated with
`
`the RSIP Server. As explained by RSIP, the RSIP Server can require that the host
`
`explicitly specify either the IP address (macro-flow) or both the IP address and
`
`port(s) (micro-flow) of the remote device, so that the RSIP Server can restrict
`
`subsequent communications. Ex. 1013, 12-13. The ability of the RSIP Server to
`
`control subsequent communications confirms to a POSITA that the allocated IP
`
`address and port are associated with the RSIP Server. Ex. 1013, 13. Of course, the
`
`RSIP Server can also chose to allow the host to not explicitly specify the remote IP
`
`address and port(s) (no remote flow policy), in which case the RSIP Server will
`
`forward all subsequent communications, regardless of the remote IP address and
`
`port. Id.; Ex. 1025, ¶9.
`
`Finally, PO’s attempt to portray RSIP as allocating something “to the host”
`
`and then attempting to portray that as inconsistent with the invention (POR, 13),
`
`fails to address the fact that the challenged patent uses the same language. Ex.
`
`1001, 5:20 (“[A]llocated to the initiating mobile device 260.”)
`
`WEST/288875011
`
`11
`
`
`
`C.
`
`Ground 3: Claims 1-3, 5-10, 12-17, and 19-20 are Unpatentable
`Over Cordenier (Ex. 1007) and TURN (Ex. 1009)
`PO does not dispute that the combination of Cordenier and TURN discloses
`
`every limitation of every claim challenged in Ground 3 as set forth in the Petition.
`
`Id. PO only argues that it would not have been obvious to a POSITA to have
`
`combined Cordenier and TURN because Cordenier’s stated goal of avoiding an IP-
`
`exchange server precludes a combination with a TURN relay server. POR, 13-16.
`
`PO’s argument is fundamentally flawed because it confuses Cordenier’s IP-
`
`exchange server with a TURN relay server. POR, 13 (erroneously stating
`
`“exchange server, i.e., a relay server”). An IP-exchange server in Cordenier is a
`
`server that (1) registers users’ IP addresses and user names, (2) responds to lookup
`
`queries from other users, and (3) exchanges IP addresses between accepting users.
`
`Ex. 1007, 1:49-2:12 (“The exchange of IP-addresses between users takes place by
`
`an IP-exchange server.”), 2:20-25 (“To be able to exchange IP-addresses . . . both
`
`users are registered at the same IP-exchange server.”). Once the users have each
`
`other’s IP addresses, the IP-exchange server is not involved in the subsequent IP-
`
`traffic. Ex. 1007, 2:13-19. Cordenier explains that an IP-exchange server can be
`
`eliminated by delivering the IP address directly from one user to another via SMS.
`
`Ex. 1007, 2:29-33, 6:49-57. Cordenier makes clear that, in its invention, the
`
`mobile devices can obtain their IP addresses from an IP address server, e.g., server
`
`15. Ex. 1007, 6:36-38, 7:9-15; Ex. 1025, ¶10.
`
`WEST/288875011
`
`12
`
`
`
`A TURN relay server is not an IP-exchange server because it does not
`
`exchange IP addresses between users or perform any of the other functions of the
`
`IP-exchange server described in Cordenier. A TURN relay server allocates one of
`
`its public IP addresses to the requesting/initiating user, but that user transmits that
`
`IP address directly to the recipient using a different application. Ex. 1009, Fig. 5
`
`(step 5), 10, 13-15; Petition, 62-63; Ex. 1002, ¶¶129-131. In the combination of
`
`Cordenier and TURN, the TURN server allocates a public IP address to the
`
`initiating user, who then transmits that address to the recipient using SMS. Id.
`
`Contrary to PO’s assertions in the POR at 14, allocating IP addresses is entirely
`
`consistent with Cordenier, wherein server 15 allocates IP addresses. Ex. 1007,
`
`6:36-38, 7:9-15. In the combination of Cordenier and TURN, there is no need for
`
`the recipient to log into the TURN server, or even know of its existence. The
`
`recipient merely responds to the public IP address contained in the SMS message,
`
`and the TURN server will then transparently relay that response to the initiating
`
`user. Petition, 64-66; Ex. 1002, ¶¶132-35; Ex. 1025, ¶11.
`
`In fact, combining Cordenier with a TURN relay server is entirely consistent
`
`with Cordenier’s teaching that it may be necessary to route IP-traffic through a
`
`network address translator, i.e., a server.
`
`Since data exchange may take place via telecom
`networks operated by different operators, it may, in the
`case the data network 3 is an IP-network, be necessary to
`
`WEST/288875011
`
`13
`
`
`
`route IP-traffic from the first and second terminal 1, 2 to
`a network address translator connected with the data
`network 3.
`
`Ex. 1007, 8:21-26 (emphasis added); Petition, 64; Ex. 1002, ¶132. Thus,
`
`consistent with the express teaching in Cordenier, a POSITA would have
`
`understood that one could still realize the advantages of Cordenier (eliminating an
`
`IP exchange server by sending IP addresses via SMS) while routing IP-traffic
`
`through a TURN relay server. Ex. 1025, ¶12.
`
`PO closes by arguing that there is no showing of a shortcoming in Cordenier
`
`that would result in a motivation to combine with TURN. POR, 16-17. PO
`
`ignores the extensive showing in the Petition, supported by Dr. Houh’s testimony,
`
`TURN and other references, 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. Petition, 12-13, 54-56;
`
`Exhibit 1002, ¶¶45-47, 115-118. PO fails to contest that testimony, for example,
`
`by offering expert testimony, or even attorney argument, explaining how that
`
`system could possibly work across NAT. A POSITA would have recognized that
`
`shortcoming and would have searched for a suitable, well-known, and standardized
`
`NAT traversal technique, leading a POSITA to TURN. Id.
`
`Finally, PO’s arguments that Dr. Houh’s testimony should be given little
`
`weight, merely because the Petition was written to closely track Dr. Houh’s
`
`WEST/288875011
`
`14
`
`
`
`testimony, is without merit. The sufficiency of expert declarations is judged by
`
`their substance, not whether the petition and expert declaration include the same
`
`language. Shopkick, Inc. v. Novitaz, Inc., IPR2015-00279, Paper 11 at 15 (PTAB
`
`Sept. 3, 2015) (“the Petition can be drafted to closely mirror an expert’s opinion”);
`
`Elekta, Inc. v. Varian Med. Sys. Int’l. AG, IPR2016-00845, Paper 11 at 7 (PTAB
`
`Sept. 28, 2016) (expert testimony is evaluated substantively, even if the petition’s
`
`language is the same).
`
`III. THE DEPENDENT CLAIMS ARE UNPATENTABLE
`PO argues that “the Petition should be denied in its entirety” because of
`
`alleged deficiencies to the independent claims. All claims are unpatentable as
`
`established above and in the Petition.
`
`IV. APJS ARE NOT UNCONSITUTIONALLY APPOINTED PRINCIPAL
`OFFICERS
`APJs are not unconstitutionally appointed principal officers under the
`
`Appointment Clause of the Constitution. Moreover, to the extent Arthrex is
`
`controlling law, the Federal Circuit has cured any defect by severing the provision
`
`of 35 U.S.C. § 3(c) that makes Title 5’s removal provisions applicable to PTAB
`
`APJs. Arthrex, Inc. v. Smith & Nephew, Inc., 941 F.3d 1320, 1337 (Fed. Cir.
`
`2019), thereby making APJs inferior officers. Thus, APJs are not
`
`unconstitutionally appointed principal officers and there is no constitutional basis
`
`for challenging a final written decision in this proceeding for that reason.
`
`WEST/288875011
`
`15
`
`
`
`V.
`
`CONCLUSION
`As established above and in the Petition, the Board should find all
`
`challenged claims unpatentable.
`
`Dated: February 11, 2020
`
`Respectfully Submitted,
`
` /Brian K. Erickson 48,895/
`Brian Erickson
`Reg. No. 48,895
`DLA Piper LLP (US)
`401 Congress Avenue, Suite 2500
`Austin, TX 78701
`brian.erickson@dlapiper.com
`Phone: 512-457-7059
`Fax: 512-721-2263
`
`James M. Heintz
`Reg. No. 41,828
`DLA Piper LLP (US)
`11911 Freedom Drive, Suite 300
`Reston, VA 20190
`Jim.heintz@dlapiper.com
`Phone: 703-773-4148
`Fax: 703-773-5200
`Attorneys for Petitioner Apple Inc.
`
`WEST/288875011
`
`16
`
`
`
`CERTIFICATE OF COMPLIANCE
`
`Under the provisions of 37 CFR § 42.24(d), the undersigned hereby certifies
`
`that the word count for the foregoing Petitioner’s Reply to Patent Owner’s
`
`Response to Petition totals 3,683, as calculated by Microsoft Word, which is less
`
`than the 5,600 allowed under 37 CFR § 42.24(c).
`
`Dated: February 11, 2020
`
` /Brian Erickson/
`Brian Erickson, Reg. No. 48,895
`
`Attorney for Petitioner Apple Inc.
`
`WEST/288875011
`
`17
`
`
`
`CERTIFICATE OF SERVICE
`
`The undersigned certifies service of a copy of this document on the Patent
`
`Owner’s counsel of record pursuant to 37 C.F.R. §§ 42.6(e) and 42.105(b) by
`
`electronic mail to the following:
`
`Ryan Loveless
`Brett Mangrum
`James Etheridge
`Jeffrey Huang
`Etheridge Law Group
`2600 E. Southlake Blvd., Suite 120-324
`Southlake, TX 76092
`ryan@etheridgelaw.com
`brett@etheridgelaw.com
`jim@etheridgelaw.com
`jeff@etheridgelaw.com
`
`Dated: February 11, 2020
`
`Respectfully Submitted,
`
` /Brian Erickson/
`Brian Erickson, Reg. No. 48,895
`
`Attorney for Petitioner Apple Inc.
`
`WEST/288875011
`
`18
`
`
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
