`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 RESPONSE TO PETITION
`
`
`
`
`
`
`
`
`
`
`Table of Contents
`
`IPR2019-00701
`Patent 8,018,877
`
`
`I.
`
`INTRODUCTION ........................................................................................... 2
`
`II.
`
`THE ’877 PATENT ......................................................................................... 2
`
`III. RELATED PROCEEDINGS .......................................................................... 4
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART ............................................. 4
`
`PETITIONER DOES NOT PROVE A REASONABLE LIKELIHOOD OF
`V.
`UNPATENTABILITY FOR ANY CHALLENGED CLAIM .................................. 5
`
`A.
`
`Claim Construction .......................................................................................... 5
`
`Kirmse Does Not Disclose “transmitting a request to a server to allocate a
`B.
`network address and port associated with the server to use in a data exchange
`session with a participating mobile device” (Ground 1) (Independent Claims 1, 8,
`15) 6
`
`Chambers and RSIP Do Not Disclose “transmitting a request to a server to
`C.
`allocate a network address and port associated with the server to use in a data
`exchange session with a participating mobile device” (Ground 2) (Independent
`Claims 1, 8, 15) .......................................................................................................... 8
`
`D. A POSITA Would Not Have Combined Cordenier and TURN (Ground 3) . 13
`
`E.
`
`The Petition fails to Prove Obviousness of Any Dependent Claim .............. 16
`
`VI. APJs are Unconstitutionally Appointed Principal Officers ........................... 17
`
`VII. CONCLUSION .............................................................................................. 18
`
`
`
`
`{00251551;v2}
`
`
`1
`
`
`
`
`
`I.
`
`INTRODUCTION
`
`IPR2019-00701
`Patent 8,018,877
`
`
`Uniloc 2017 LLC (the “Patent Owner” or “Uniloc”) submits its Response to
`
`the Petition for Inter Partes Review (“Pet.” or “Petition”) of United States Patent
`
`No. 8,018,877 (“the ’877 patent” or “EX1001”) filed by Apple Inc. (“Petitioner”) in
`
`IPR2019-00701. The Petition is procedurally and substantively defective.
`
`II. THE ’877 PATENT
`
`The ’877 patent is titled “Mobile conferencing method and system.” The ʼ877
`
`patent issued September 13, 2011, from U.S. Patent Application No. 13/079,767
`
`filed April 4, 2011, which is a continuation of application No. 12/691,594, filed on
`
`January 21, 2010, now Pat. No. 7,940,704, which is a continuation of application
`
`No. 11/091,242, filed on March 28, 2005, now Pat. No. 7,672,255, and a
`
`continuation-in-part of application No. 10/935,342, filed on September 7, 2004, now
`
`Pat. No. 7,764,637, which is a continuation-in-part of application No. 10/817,994,
`
`filed on April 5, 2004, now Pat. No. 7,961,663, and a continuation-in-part of
`
`application No. 11/042,620, filed on January 24, 2005, now Pat. No. 7,773,550.
`
`The inventors of the ’877 patent observed that, at the time, mobile instant
`
`messaging (“IM”) had just begun to become available and was not as easy to use in
`
`the mobile environment as it was in the desktop environment. In particular, the
`
`then-current IM paradigm was encumbered by the constraint that one can only
`
`communicate with those who are currently (i) online, (ii) logged on to same IM
`
`{00251551;v2}
`
`
`2
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`service such as AOL's Instant Messenger (AIM), Yahoo! Messenger or MSN
`
`Messenger, and (iii) included as a “buddy” on one's “buddy list.” And while at the
`
`time there were also peer-to-peer instant messaging systems, those peer-to-peer
`
`techniques also had their limitations. Specifically, with pure peer-to-peer IM
`
`techniques, it was more difficult to implement a commercially viable IM system
`
`that efficiently incorporated the capability to communicate in a real-time messaging
`
`session with more than two devices (i.e., adding conferencing capabilities to an IM
`
`system). Additionally, to the extent service providers dynamically allocated private
`
`IP addresses (rather than allocate public Internet IP addresses) to mobile devices
`
`through Network Address Translation (NAT) or any other network address
`
`allocation techniques, peer-to-peer IM techniques generally would only work within
`
`the private network of the service provider since the private IP addresses allocated
`
`to a mobile device would not be properly resolved by a receiving mobile device
`
`residing on a separate private network with a separate service provider. EX1001,
`
`1:30-2:18.
`
`The ’877 patent describes methods and systems for establishing a real-time
`
`session-based IM system or data exchange system between mobile devices over a
`
`digital mobile network system that supports data packet-based communications.
`
`One such method for initiating a data exchange session among mobile devices
`
`comprises transmitting a request to a server to allocate a network address and port
`
`{00251551;v2}
`
`
`3
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`associated with the server to use in a data exchange session with a participating
`
`mobile device, receiving the network address and port from the server, using a
`
`page-mode messaging service to assist in communicating the network address and
`
`port to the participating mobile device, wherein the page-mode messaging service
`
`utilizes a unique identifier to locate the participating mobile device, and
`
`participating in the data exchange session with the participating mobile device
`
`through the server, wherein the participating mobile device has established a
`
`connection with the server using the network address and port. EX1001, 2:22-39.
`
`III. RELATED PROCEEDINGS
`
`There are no pending cases concerning U.S. Pat. No. 8,018,877 (EX1001).
`
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`The Petition alleges that “[a] person of ordinary skill in the art at the time of
`
`the alleged invention of the ‘877 patent (a “POSITA”) would have had a Bachelors’
`
`degree in computer science or a comparable field of study, plus approximately two
`
`to three years of professional experience with cellular phone and IP networks, or
`
`other relevant industry experience.” Pet. 10. Given that Petitioner fails to meet its
`
`burden of proof when purportedly applying its own definition of a person of ordinary
`
`skill in the art, Patent Owner does not offer a competing definition for purposes of
`
`this proceeding. Furthermore, again because Petitioner fails to meet it burden of
`
`{00251551;v2}
`
`
`4
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`proof, Patent Owner does not offer competing analysis of the Petition’s allegations
`
`regarding the knowledge of a POSITA. See Pet. 11-13.
`
`V.
`
`PETITIONER DOES NOT PROVE A REASONABLE LIKELIHOOD
`OF UNPATENTABILITY FOR ANY CHALLENGED CLAIM
`
`The Petition raises the following Section 103 challenges:
`
`
`
`Ground
`1
`2
`3
`
`Claims
`
`Reference(s)
`Kirmse1, and Chambers2
`1-20
`Chambers and RSIP3
`1-20
`
`1-3, 5-10, 12-17, 19-20 Cordenier4 and TURN5
`
`
`A. Claim Construction
`
`In IPR proceedings, claim terms are to be given a construction utilizing the
`
`standard applied by Article III courts. 37 C.F.R. §42.100(b); Phillips v. AWH Corp.,
`
`415 F.3d 1303 (Fed. Cir. 2005). Under Phillips, a claim term must be given “the
`
`meaning that the term would have to a person of ordinary skill in the art in question
`
`at the time of the invention.” Phillips, 415 F.3d at 1313. The Phillips standard
`
`primarily focuses on intrinsic evidence, such as the patent specification and
`
`
`1 EX1005, U.S. Patent No. 6,699,125.
`
`2 EX1006, U.S. Patent Application Publication No. 2003/0142654.
`
`3 EX1013, Realm Specific IP: Protocol Specification.
`
`4 EX1007, EP 1 385 323 A1.
`
`5 EX1009, Draft Request for Comment published by IETF.
`
`{00251551;v2}
`
`
`5
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`prosecution history, to interpret the claim terms. Id. at 1317; see also 37 C.F.R. §
`
`42.100(b).
`
`Patent Owner submits that the Board need not construe any claim term in a
`
`particular manner in order to arrive at the conclusion that the Petition is
`
`substantively deficient. Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361
`
`(Fed. Cir. 2011) (“need only be construed to the extent necessary to resolve the
`
`controversy”).
`
`B. Kirmse Does Not Disclose “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” (Ground 1) (Independent Claims 1, 8, 15)
`
`In Ground 1, the Petition relies solely on Kirmse for this limitation. See Pet.
`
`18-20. Kirmse does not disclose transmitting a request to the server to allocate a
`
`network address and port associated with the server, as required by the claim
`
`language.
`
`The Institution Decision, in its analysis on pages 13-14, seeks to
`
`impermissibly rewrite 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
`
`{00251551;v2}
`
`
`6
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`active game with existing connection details, and providing of the inviter with the
`
`existing connection details, with the claimed recitation of transmitting a request to a
`
`server to allocate a network address and port associated with the server. 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).
`
`The Petitioner’s Expert’s Declaration in this regard should be given little or
`
`no weight. The Declaration, in discussing Kirmse, mischaracterizes Kirmse, by
`
`stating that the connection details include the server’s IP address and the game
`
`instance’s port number. (EX. 1002; Para. 51). In fact, in Kirmse, a “specific port
`
`reference or URL string…specifies a specific game in progress.” (EX. 1005; 5:59-
`
`62). The Petitioner’s Expert thus fails to acknowledge that Kirmse may provide
`
`identification of a specific game in progress via a URL string, as opposed to a port.
`
`In contrast, Kirmse itself confirms that the “URL string for the game server,
`
`with a specific port reference… is known to the game client … or can be
`
`obtained by the game client.” Thus, under Kirmse, a request is not transmitted to the
`
`game server to allocate a network address and port associated with the server,
`
`because the game server serves active games and that information is already known
`
`to, or can be obtained by, the game client.
`
`Still further, the Petitioner’s Expert fails to even use the claim term
`
`“allocate” in providing its overview of Kirmse. (EX. 1002; Para. 51). Only when
`
`{00251551;v2}
`
`
`7
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`discussing the specific claim language does Petitioner’s Expert, without explanation
`
`or analysis, abruptly begin to characterize features of Kirmse, previously described
`
`without reference to the term “allocate”. Compare (EX. 1002, Para. 51 and Para.
`
`56). Such mischaracterization points out a fatal error in Petitioner’s interpretation
`
`“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”
`
`with the disclosure of Kirmse, wherein the game server serves up an active game
`
`(S3) and provides (S4) the inviter with enough information, including an IP address
`
`and port number, so that the inviter can join and play the already-active game.
`
`There is nothing in Kirmse that discloses a mobile device requesting to allocate a
`
`network address and port associated with the server. The Institution Decision’s
`
`conclusion that Kirmse teaches the above-identified recitation rests entirely on this
`
`flawed analysis.
`
`Accordingly, Kirmse does not teach “transmitting a request to a server to
`
`allocate a network address and port associated with the server” as required by
`
`the claim language, and thus Ground 1 fails.
`
`C. Chambers and RSIP Do Not Disclose “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” (Ground 2) (Independent
`Claims 1, 8, 15)
`
`{00251551;v2}
`
`
`8
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`In Ground 2, the Petition relies on the proposed combination of Chambers
`
`
`
`and RSIP for this limitation. See Pet. 40-41. However, neither Chambers nor RSIP
`
`discloses the required request from a mobile device to allocate a network address
`
`and port associated with the server.
`
`The Petition does not rely on Chambers for allocating a network address and
`
`port associated with the server. In fact, the Petition admits that in the system of
`
`Chambers, a (temporary) IP address is allocated to the mobile device. Pet. 40
`
`(“initiating mobile phone requests IP address from stationary server…”); Pet. 34.
`
`However, RSIP does not disclose the required allocating a network address and port
`
`associated with the server either.
`
`In the Institution Decision, the Board states that “The Petition relies on the
`
`RSIP server as the claimed server.” Ex. 7, p. 18. The claim language expressly
`
`requires that the allocated “network address” and “port” be associated with “the
`
`server”.
`
`However, the Institution Decision does not provide any evidence that
`
`contradicts Patent Owner’s assertion that the combination of Chambers and RSIP
`
`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.” The Institution Decision contends that “Petitioner has shown that
`
`the RSIP server controls port numbers (of the server) to be allocated to RSIP hosts.”
`
`{00251551;v2}
`
`
`9
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`Ex. 7, p. 18. However, the support cited to by the Institution Decision does not
`
`teach transmitting a request to a server to allocate a network address and port
`
`associated the RSIP server. First, the Institution Decision quotes from the RSIP
`
`Protocol Specifications:
`
`See, e.g., Ex. 1013, 10, 12 (“In other words, an RSIP gateway should
`
`have the ability to explicitly control which local addresses and ports
`
`are used to communicate with remote addresses and ports”).
`
`Paper 7, p. 18. The statement that the RSIP gateway (i.e., the RSIP server) should
`
`control its own local addresses and ports is not a teaching that the RSIP server
`
`receives a request and allocates a network address and port associated with the
`
`server (local RSIP server) for sending to other devices.
`
`The Institution Decision also contends that Petitioner has demonstrated that
`
`the server allocates address and port number of the server because “[t]he
`
`ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP gateway to deliver
`
`parameter assignments to an RSIP host . . . .” Paper 7, p. 18. The statement “to
`
`deliver parameter assignments” does not specify whether the parameters refer to
`
`server ports or local ports of the mobile devices. In fact, as discussed in detail in
`
`the Preliminary Response at pages 12-14, the description of the related
`
`ASSIGN_REQUEST_RSAP-IP
`
`message
`
`indicates
`
`that
`
`the
`
`“ASSIGN_REQUEST_RSAP-IP” message contains
`
`two address and port
`
`{00251551;v2}
`
`
`10
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`parameters, one for the RSIP Host itself (a.k.a. a mobile device), or the local
`
`address and port(s), and the second of each to refer to the remote address and port(s)
`
`that will be contacted:
`
`
`
`
`EX10136 at p. 27 (highlighting and underlining added). In other words, of the two
`
`
`
`addresses and ports specified, one set is the local to the requesting mobile
`
`device, and the second set is for the mobile device that is to be contacted. Thus,
`
`neither the description for the ASSIGN_RESPONSE_RSAP-IP nor the description
`
`for the ASSIGN_REQUEST_RSAP-IP teaches allocation of a network address and
`
`port associated with the RSIP gateway (a.k.a. server).
`
`
`
`The Petition’s reliance on RSIP’s “LISTEN_REQUEST” is similarly
`
`unavailing:
`
`
`6 The page numbers refer to the page numbers added by Petitioner at the bottom
`
`right of EX1013.
`
`{00251551;v2}
`
`
`11
`
`
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`
`EX1013 at 36 (highlighting and underlining added).
`
`
`
`As seen above, the “LISTEN_REQUEST” message also contains two address
`
`and port parameters, and similarly, the address and port parameters come in two
`
`sets: local and remote. Therefore, just as with the “ASSIGN_REQUEST_RSAP-IP”
`
`message, there is nothing in the “LISTEN_REQUEST” message regarding a request
`
`to allocate a network address and port associated with the RSIP Gateway (a.k.a.
`
`the server).
`
`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.
`
`mobile devices) communicate without explicitly notifying the gateway (a.k.a. the
`
`server):
`
`
`
`
`
`EX1013 at 13 (highlighting and underlining added).
`12
`
`{00251551;v2}
`
`
`
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`The above 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.
`
`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.
`
`D. A POSITA Would Not Have Combined Cordenier and
`TURN (Ground 3)
`
`In Ground 3, the Petition proposes the combination of Cordenier and TURN.
`
`However, the primary reference itself demonstrates the fatal flaw in Petitioner’s
`
`argument. 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;
`
`Para. [0006].) As TURN requires an exchange server, i.e., a relay server, a
`
`POSITA, seeking to modify Cordenier’s peer-to-peer communication approach
`
`without an exchange server, would not incorporate TURN.
`
`The Declaration of Petitioner’s Expert fails to address this fundamental
`
`incompatibility between the goal of Cordenier of providing a peer-to-peer network
`
`{00251551;v2}
`
`
`13
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`without a server, and TURN’s provision of a server. Indeed, Petitioner’s Expert, in
`
`summarizing Cordenier, describes Cordenier as disclosing “a method for initiating
`
`an IP-based data exchange session…between mobile devices” (EX. 1002; Para.
`
`106), without mentioning that the object of Cordenier is to avoid “the need of a
`
`common exchange server.” (EX. 1007; Para. [0006]).
`
`Indeed, the Board’s own decision states that “Petitioner relies on TURN for
`
`its teaching of transmitting a request (Allocate Request) to a server (TURN server)
`
`to allocate a network address and port associated with the server (public IP address
`
`and port number of the TURN server) to use in a data exchange session (e.g., relay)
`
`with a participating mobile device (peer).” (Paper No. 7, p. 24). 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; Para.
`
`[0005]).
`
`Moreover, the purported motivation to combine Cordenier and TURN, as
`
`provided by Petitioner’s Expert at Paragraphs 113-118 of Exhibit 1002, makes no
`
`mention of Cordenier’s object of avoiding a common exchange server. Indeed,
`
`Petitioner’s Expert specifically states that TURN is “advantageous because it uses
`
`public addresses that are guaranteed to be accessible to every peer.” (EX. 1002;
`
`Para. 116). However, in TURN, those public addresses are made available by the
`
`{00251551;v2}
`
`
`14
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`TURN server, and the TURN server acts as a relay, forwarding data received at the
`
`public IP address to a stored source IP address and port. (EX.1009; 8). Thus, one of
`
`the very reasons that Petitioner’s Expert cites in favor of combining TURN with
`
`Cordenier is that TURN provides a relay server storing IP addresses, which n fact
`
`is what Cordenier is seeking to avoid.
`
`Patent Owner notes that the Institution Decision contends that “Patent Owner
`
`does not take into account the testimony of Dr. Houh” in arguing that “Petitioner
`
`does not identify any shortcomings of Cordenier that would cause a person having
`
`ordinary skill in the art to look to TURN, or vice versa, and that the Petition merely
`
`offers hindsight reconstruction.” Paper 7 at pp. 24-25. Patent Owner disagrees. In
`
`fact, the Preliminary Response clearly includes discussion of Dr. Houh’s testimony
`
`in EX1002, noting that it merely parrots the same speculative and conclusory
`
`statement of the Petition:
`
`Yet, the Petition argues that “[b]ecause Cordenier does not provide any
`
`NAT traversal technique, a POSITA would have been motivated to
`
`search for and use a known NAT traversal technique…” Pet. 54.
`
`However, the Petition does not provide any evidence or analysis for
`
`this conclusion, instead, the Petition merely cites to its declarant for
`
`support. Id. citing EX1002, ¶ 115. But Petitioner’s declarant merely
`
`parrots the same speculative and conclusory statement of the Petition.
`
`Compare Pet. 54 with EX1002, ¶ 115. That is insufficient. 37 C.F.R. §
`
`42.65(a) (“Expert testimony that does not disclose the underlying facts
`
`{00251551;v2}
`
`
`15
`
`
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`or data on which the opinion is based is entitled to little or no
`
`weight.”); Alza Corp. v. Mylan Labs., Inc., 464 F.3d 1286, 1290 (Fed.
`
`Cir. 2006) (“legal determinations of obviousness, as with such
`
`determinations generally, should be based on evidence rather than on
`
`mere speculation or conjecture.”); In re Magnum Oil Tools Int’l Ltd.,
`
`829 F.3d 1364, 1380 (Fed. Cir. 2016) (“[A] petitioner cannot employ
`
`mere conclusory statements” and “must instead articulate specific
`
`reasoning, based on evidence of record . . . .”).
`
`Preliminary Response at p. 19. Accordingly, the Institution Decision is
`
`incorrect that the Patent Owner does not take into account the testimony of Dr.
`
`Houh, and Patent Owner reiterates that legal determinations of obviousness must be
`
`based on evidence, not expert testimony based upon speculation and conjecture.
`
`Further, to the extent that TURN purportedly identifies problems with NAT,
`
`Patent Owner submits that a generalized showing of problems with NAT is not a
`
`showing of shortcomings of Cordenier that would cause a POSITA familiar with
`
`Cordenier to look to TURN, or vice versa. Instead, 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.
`
`E. The Petition fails to Prove Obviousness of Any Dependent Claim
`
`{00251551;v2}
`
`
`16
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`The deficiencies of the Petition articulated above concerning the challenged
`
`
`
`independent claims apply also taint the analysis of the challenged dependent claims.
`
`Accordingly, the Petition should be denied in its entirety.
`
`VI. APJs are Unconstitutionally Appointed Principal Officers
`
`As determined in Arthrex, Inc. v. Smith & Nephew, Inc., ___ F.3d ___,
`
`2019 WL 5616010, at *5 (Fed. Cir. 2019), “APJs have substantial power to issue
`
`final decisions on behalf of the United States without any review by a
`
`presidentially-appointed officer.” Patent Owner submits that APJs are principal
`
`officers under the Appointments Clause of the Constitution for this reason, but
`
`undisputedly are not appointed through the constitutionally-mandated mechanism
`
`of appointment for principal officers. Contrary to Arthrex, Patent Owner submits
`
`that the Arthrex decision’s remedy (partial invalidation of the statutory limitations
`
`on removal of APJs) impermissibly re-writes the statutes governing APJs. In
`
`addition, the ability to remove APJs at will is insufficient to render APJs inferior
`
`officers. The importance placed on review of the decisions of Court of Criminal
`
`Appeals Judges in Edmond v. US, 520 U.S. 651 (1997), is inconsistent with
`
`Arthrex’s determination that partial invalidation of statutory limitations on the
`
`removal of APJs is sufficient to render APJs inferior officers. See Edmond, 520
`
`U.S. at 665 (“What is significant is that the judges of the Court of Criminal
`
`{00251551;v2}
`
`
`17
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`Appeals have no power to render a final decision on behalf of the United States
`
`
`
`unless permitted to do so by other Executive officers.”).
`
`In view of these issues, only Congress can fix the IPR statutory scheme,
`
`and this case must be dismissed. Although Patent Owner recognizes that this
`
`argument perhaps would be more appropriately presented on appeal of any
`
`adverse decision in this matter, and should be considered timely if so presented,
`
`see Arthrex, 2019 WL 5616010, at *11, Patent Owner raises the issues here in
`
`view of the government’s continuing arguments that such issues must be brought
`
`before the Board, see, e.g., id.
`
`VII. CONCLUSION
`
`For at least the reasons set forth above, Uniloc respectfully requests that the
`
`Board deny all challenges in the instant Petition.7
`
`
`
`
`
`
`
`
`7 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.
`
`
`
`
`
`
`
`
`
`{00251551;v2}
`
`
`18
`
`
`
`Date: November 19, 2019
`
`Respectfully submitted,
`
`IPR2019-00701
`Patent 8,018,877
`
`
`
`
`
`
`By: / Brett A. Mangrum /
`Brett A. Mangrum
`Reg. No. 64,783
`Attorney for Patent Owner
`
`{00251551;v2}
`
`
`19
`
`
`
`
`
`
`
`
`
`
`CERTIFICATE OF COMPLIANCE
`
`IPR2019-00701
`Patent 8,018,877
`
`
`Pursuant to 37 C.F.R. § 42.24(d), we certify that this Patent Owner
`
`Response to Petition complies with the type-volume limitation of 37 C.F.R.
`
`§ 42.24(b)(1) because it contains fewer than the limit of 14,000 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(a)(1).
`
`Date: November 19, 2019
`
`
`
`Respectfully submitted,
`
`By: / Brett A. Mangrum /
`Brett A. Mangrum
`Reg. No. 64,783
`Attorney for Patent Owner
`
`{00251551;v2}
`
`i
`
`
`
`IPR2019-00701
`Patent 8,018,877
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. §§ 42.6(e), we certify that we served an electronic
`
`copy of the foregoing PATENT OWNER RESPONSE TO PETITION, along with
`
`any accompanying exhibits filed via the PTAB E2E system, 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: November 19, 2019
`
`
`
`Respectfully submitted,
`
`
`
`
`
`
`
`
`
`
`
`By: / Brett A. Mangrum /
`Brett A. Mangrum
`Reg. No. 64,783
`Attorney for Patent Owner
`
`
`
`{00251551;v2}
`
`ii
`
`
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
