Trials@uspto.gov
`571-272-7822
`
` Paper 17
`Entered: August 17, 2020
`
`
`
`
`
`
`
`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 B2
`____________
`
`
`
`Before SALLY C. MEDLEY, JEFFREY S. SMITH, and
`JOHN F. HORVATH, Administrative Patent Judges.
`
`MEDLEY, Administrative Patent Judge.
`
`
`
`JUDGMENT
`Final Written Decision
`Determining All Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`I. INTRODUCTION
`Apple Inc. (“Petitioner”) filed a Petition for inter partes review of
`claims 1–20 of U.S. Patent No. 8,018,877 B2 (Ex. 1001, “the ’877 patent”).
`Paper 1 (“Pet.”). Uniloc 2017 LLC (“Patent Owner”) filed a Preliminary
`Response. Paper 6 (“Prelim. Resp.”). Upon consideration of the Petition
`and Preliminary Response, we instituted inter partes review, pursuant to 35
`U.S.C. § 314, as to claims 1–20 based on all challenges set forth in the
`Petition. Paper 7 (“Decision to Institute” or “Dec.”).
`Subsequent to institution, Patent Owner filed a Patent Owner
`Response (Paper 9, “PO Resp.”), Petitioner filed a Reply to Patent Owner’s
`Response (Paper 10, “Pet. Reply”), and Patent Owner filed a Sur-reply
`(Paper 11, “Sur-reply”). On May 21, 2020, we held an oral hearing. A
`transcript of the hearing is of record. Paper 16 (“Tr.”).
`In our Scheduling Order, we notified the parties that “any arguments
`not raised in the [Patent Owner] response may be deemed waived.” See
`Paper 8, 7; see also Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756,
`48,766 (Aug. 14, 2012) (“The patent owner response . . . should identify all
`the involved claims that are believed to be patentable and state the basis for
`that belief.”). Patent Owner argues that it “does not concede, and
`specifically denies, that there is any legitimacy to any arguments in the
`instant Petition that are not specifically addressed” in its Patent Owner
`Response. PO Resp. 18 n.7. We decline to speculate as to what arguments
`Patent Owner considers illegitimate in the Petition. Any arguments for
`patentability not raised in the Patent Owner Response are deemed waived.
`For the reasons that follow, we conclude that Petitioner has proven by
`a preponderance of the evidence that claims 1–20 of the ’877 patent are
`unpatentable.
`
`2
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`A. Related Matters
`Petitioner and Patent Owner identify Uniloc USA, Inc., et al. v. Apple
`Inc., Case No. 1:18-cv-00166-LY (W.D. Tex.) as related to the issues
`presented in this proceeding. Pet. 1; Paper 4, 2.
`Petitioner additionally filed proceedings challenging related patents
`belonging to Patent Owner (which we instituted): IPR2019-00700 (U.S.
`Patent No. 8,406,116 B2) and IPR2019-00702 (U.S. Patent No. 7,969,925
`B2). Pet. 1–2.
`
`B. The ’877 Patent1
`The ’877 patent is directed to methods and a server-based architecture
`for establishing data exchange between multiple mobile devices. Ex. 1001,
`code (57). According to the Specification, several instant messaging (“IM”)
`paradigms have been developed to take advantage of the growing IM
`market. Id. at 1:31–65. However, each of those paradigms are limited by
`system compatibility (id. at 1:38–43), or the failure to allow for real-time
`communication between more than two mobile devices. Id. at 1:65–2:4.
`Accordingly, the invention addresses these problems by creating (1) a
`session-based IM architecture and (2) data transfer techniques for
`establishing data exchange between multiple mobile devices. Id. at 2:22–25.
`An example of a digital mobile network system is illustrated in Figure
`1, reproduced below:
`
`
`1 Petitioner argues that the effective filing date of the ’877 patent is no
`earlier than March 28, 2005. Pet. 8–10. For purposes of this Decision, we
`need not determine the effective filing date of the ’877 patent.
`
`3
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`
`
`Figure 1 is a diagram of a Global System for Mobile communications
`(GSM) mobile networking system 100 including a first mobile device 105
`and a second mobile device 110. Id. at 2:64–3:5. As disclosed in the
`Specification, each of the mobile devices 105 and 110 includes a Subscriber
`Information Module (SIM) card that contains unique identification
`information that enables the GSM system 100 to locate the mobile devices
`within the network and route data to them. Id. at 3:1–5. The Specification
`further discloses that the GSM system 100 supports a page-mode messaging
`service, such as Short Message Service (SMS), that relies upon the
`underlying GSM mechanisms to resolve routing information in order to
`locate destination mobile devices. Id. at 3:42–46; see also id. at 3:57–4:4
`(describing a typical transmission of an SMS text message from the
`initiating mobile device 105 to the receiving mobile device 110).
`Generally, the invention initiates data exchange between multiple
`mobile devices by first receiving, at a server, a request from the initiating
`
`4
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`mobile device to allocate a session identifier to use for data exchange. Id. at
`2:25–40. Once the session identifier has been allocated, the server transmits
`the session identifier to the initiating mobile device, whereupon the initiating
`mobile device communicates the session identifier to the participating
`mobile device. Id. Once the initiating mobile device and participating
`mobile device have the session identifier, the session identifier is used to
`establish a connection at the server, whereby data exchange is facilitated. Id.
`
`Figure 2, reproduced below, illustrates a flow chart depicting one
`embodiment of a server-based architecture in accordance with the present
`invention:
`
`In Figure 2, the initiating device transmits a request 215 to establish a
`connection with a server. Id. at 4:55–59. Once the connection between the
`server and initiating device is established 220, the server transmits a port
`number to the initiating mobile device, which receives the port number 235,
`
`
`
`5
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`and propagates the server information in an invitation to other mobile
`devices through a page-mode messaging service such as SMS. Id. at 4:60–
`5:8. The invited mobile devices can use this information to request a server
`connection in the event they wish to join the IM session. Id. at 5:15–20. As
`illustrated in box 260, the server can establish connections with mobile
`devices requesting participation in the IM session, and monitors all
`connections in addition to forwarding all messages between participating
`mobile devices. Id. at 5:20–30.
`
`C. Illustrative Claim
`Petitioner challenges claims 1–20 of the ’877 patent. Claims 2–7
`depend either directly or indirectly from independent claim 1; claims 9–14
`depend either directly or indirectly from independent claim 8; and claims
`16–20 depend either directly or indirectly from independent claim 15.
`Claim 1 is reproduced below:
`1. A method of initiating a data exchange session
`among mobile devices, the method comprising:
`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;
`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.
`Ex. 1001, 8:20–35.
`
`6
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`D. Instituted Grounds of Unpatentability
`We instituted trial based on all asserted grounds of unpatentability
`under 35 U.S.C.2 as follows (Dec. 6, 27):
`Claim(s) Challenged
`35 U.S.C. §
`1–20
` 103(a)
`1–20
` 103(a)
`1–3, 5–10, 12–17, 19, 20
` 103(a)
`II. ANALYSIS
`
`Reference(s)/Basis
`Kirmse3, Chambers4
`Chambers, RSIP5
`Cordenier6, TURN7
`
`A. Principles of Law
`To prevail in its challenges to Patent Owner’s claims, Petitioner must
`demonstrate by a preponderance of the evidence8 that the claims are
`unpatentable. 35 U.S.C. § 316(e) (2012); 37 C.F.R. § 42.1(d) (2018). A
`
`
`2 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. §§ 102 and 103. Because the ’877
`patent has an effective filing date before the effective date of the applicable
`AIA amendments, we refer to the pre-AIA versions of 35 U.S.C. §§ 102 and
`103.
`3 U.S. Patent No. 6,669,125 B2, issued Mar. 2, 2004 (Ex. 1005, “Kirmse”).
`4 U.S. Patent Application Pub. No. U.S. 2003/0142654 A1, published July
`31, 2003 (Ex. 1006, “Chambers”).
`5 Realm Specific IP: Protocol Specification, RFC 3103, published by IETF
`no later than Oct. 2001, and Declaration of Sandy Ginoza (Ex. 1013,
`“RSIP”).
`6 European Patent Application Publication No. EP 1 385 323 A1, published
`Jan. 28, 2004 (Ex. 1007, “Cordenier”).
`7 Draft-rosenberg-midcom-turn-00, Traversal Using Relay NAT, published
`by IETF no later than November 14, 2001, and Declaration of Alexa Morris
`(Ex. 1009, “TURN”).
`8 The burden of showing something by a preponderance of the evidence
`requires the trier of fact to believe that the existence of a fact is more
`probable than its nonexistence before the trier of fact may find in favor of
`the party who carries the burden. Concrete Pipe & Prods. of Cal., Inc. v.
`Constr. Laborers Pension Tr. for S. Cal., 508 U.S. 602, 622 (1993).
`
`7
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`patent claim is unpatentable under 35 U.S.C. § 103(a) if the differences
`between the claimed subject matter and the prior art are such that the subject
`matter, as a whole, would have been obvious at the time the invention was
`made to a person having ordinary skill in the art to which said subject matter
`pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007).
`The question of obviousness is resolved on the basis of underlying factual
`determinations including (1) the scope and content of the prior art; (2) any
`differences between the claimed subject matter and the prior art; (3) the level
`of ordinary skill in the art; and (4) when in evidence, objective evidence of
`nonobviousness.9 Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966).
`
`B. Level of Ordinary Skill
`In determining the level of ordinary skill in the art, various factors
`may be considered, including the “type of problems encountered in the art;
`prior art solutions to those problems; rapidity with which innovations are
`made; sophistication of the technology; and educational level of active
`workers in the field.” In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995)
`(citation omitted). Petitioner relies on the testimony of Dr. Henry Houh,
`who testifies that a person with ordinary skill in the art 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
`(citing Ex. 1002 ¶ 42). Dr. Houh further testifies that additional graduate
`education could substitute for professional experience, and significant
`
`
`9 Patent Owner does not present any objective evidence of nonobviousness
`as to the challenged claims.
`
`8
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`experience in the field could substitute for formal education. Ex. 1002 ¶ 42.
`Patent Owner does not propose an alternative assessment. PO Resp. 4–5.
`We adopt Dr. Houh’s assessment of a person with ordinary skill in the
`art as it is consistent with the ’877 patent and the asserted prior art. We
`further note that the prior art of record in the instant proceeding reflects the
`appropriate level of ordinary skill in the art. Cf. Okajima v. Bourdeau, 261
`F.3d 1350, 1354–55 (Fed. Cir. 2001) (holding the Board may omit specific
`findings as to the level of ordinary skill in the art “where the prior art itself
`reflects an appropriate level and a need for testimony is not shown”).
`
`C. Claim Construction
`In an inter partes review for a petition filed on or after November 13,
`2018, “[claims] of a patent . . . shall be construed using the same claim
`construction standard that would be used to construe the [claims] in a civil
`action under 35 U.S.C. § 282(b), including construing the [claims] in
`accordance with the ordinary and customary meaning of such claims as
`understood by one of ordinary skill in the art and the prosecution history
`pertaining to the patent.” See Changes to the Claim Construction Standard
`for Interpreting Claims in Trial Proceedings Before the Patent Trial and
`Appeal Board, 83 Fed. Reg. 51,340, 51,358 (Oct. 11, 2018) (amending 37
`C.F.R. § 42.100(b) effective November 13, 2018) (now codified at
`37 C.F.R. § 42.100(b) (2019)); see also Phillips v. AWH Corp., 415 F.3d
`1303, 1312– 14 (Fed. Cir. 2005).
`For purposes of this Decision, we need not expressly construe any
`claim term. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999) (holding that “only those terms need be construed that
`are in controversy, and only to the extent necessary to resolve the
`
`9
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`controversy”); see also Nidec Motor Corp. v. Zhongshan Broad Ocean
`Motor Co. Matal, 868 F.3d 1013, 1017 (Fed. Cir. 2017) (citing Vivid Techs.
`in the context of an inter partes review).
`
`D. Asserted Obviousness of Claims 1–20 over Chambers and RSIP
`Petitioner contends claims 1–20 are unpatentable under 35 U.S.C.
`§ 103(a) as obvious over Chambers and RSIP. Pet. 34–48. In support of its
`showing, Petitioner relies upon the declaration of Dr. Houh. Id. (citing
`Ex. 1002 ¶¶ 76–105).
`
`1. Chambers
`Chambers describes a method and communication system for a
`plurality of users, in which an invitation message that includes an IP address
`is sent from one user to a plurality of other users who accept and reply to the
`invitation message to initiate a chat session. Ex. 1006, code (57). Figure 2
`illustrates a flow diagram of a preferred embodiment of a method of
`providing a communication session in accordance with the principles of
`Chambers’s invention. Id. ¶ 26.
`
`10
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`
`
`Specifically, as illustrated in Figure 2, in a preferred embodiment, a user of
`an initiator terminal creates a member list 44, after which an IP address for
`the initiator terminal is requested 46. Id. ¶¶ 27–29. After the IP address is
`requested, the user sends an invitation message, in the form of a SMS-
`message, to the member list 48, and once the SMS-message is received 50,
`each member can decide whether to accept the message 52. Id. ¶¶ 30–33.
`
`11
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`Upon accepting the invitation, an invited member activates a GPRS session
`54, which can include requesting an IP address, and sends a reply to the
`invitation message 56. Id. ¶¶ 34–35. After receiving the reply 58, the
`initiating terminal marks the replying member as active 60, and if the reply
`is a first reply 61, activates the chat session 62, after which any active
`member can send data 68 to other active members. Id. ¶¶ 37–39, 43. If at
`step 61, the reply is not a first reply, then the active member list is updated
`64 to indicate the IP addresses of all active members, and the active member
`list is transmitted 66 to all active members. Id. ¶¶ 47–48. The chat session
`ends when the initiating terminal sends a “TERMINATE” message to the
`active session.” Id. ¶ 46.
`
`2. RSIP
`RSIP (Realm Specific IP) is a technical specification that describes
`a method for assigning parameters to an RSIP Host from an RSIP Gateway.
`Ex. 1013, 5.10 RSIP describes a method for address sharing that allows a
`host having an IP address in a first network address space to request
`allocation of a second IP address in a second network address space from an
`RSIP Server. Id. at 7. On page 10 of RSIP is a diagram, which is
`reproduced below:
`
`
`
`
`10 Petitioner cites to the page numbers added by Petitioner in the lowest right
`corner. We cite to the same.
`
`12
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`In this illustration, host X belongs to first network addressing realm A; host
`Y belongs to second network addressing realm B; and N is an RSIP
`Gateway. Id. at 10. In order to establish a connection between host X and
`host Y, host X negotiates and obtains an assignment of resources from the
`RSIP Gateway (i.e., a network address and port number in addressing realm
`B). Id. (disclosing gateway “N may have a pool of addresses in address
`space B which it can assign to or lend to X”); see also id. at 9 (defining a
`resource as “an item that an RSIP host leases from an RSIP gateway; e.g., an
`address or port”). Upon assignment of these resources, the RSIP Gateway
`creates a mapping of X’s addressing information in addressing realm A and
`the assigned resources (i.e., the network address and port number for X in
`addressing realm B). Id. at 10. This enables RSIP Gateway to correctly de-
`multiplex and forward inbound traffic generated by Y for X. Id. RSIP
`describes an “RSIP Server” as an application program that performs the
`server portion of the RSIP client/server protocol, and indicates that an RSIP
`Server exists on all RSIP Gateways. Id. at 10.11
`
`3. Discussion
`Claim 1 recites a “method of initiating a data exchange session among
`mobile devices.”12 Petitioner contends, and we agree, that Chambers in
`combination with RSIP describes a method of initiating a data exchange
`session (chat session) among mobile devices (mobile phones) via an RSIP
`
`
`11 Petitioner refers to the RSIP Gateway running an RSIP Server,
`collectively as the “RSIP Server.” Pet. 35. Patent Owner appears to do the
`same (PO Resp. 10) as do we.
`12 We need not resolve the issue of whether the preamble is limiting
`because, regardless of whether the preamble is limiting, Petitioner shows
`that the combination of Chambers and RSIP meets the preamble.
`
`13
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`Server. Pet. 39–40 (citing showing for limitations 1.a–1.e; Ex. 1006, Figs.
`1–2, ¶¶ 22, 26–39; Ex. 1013, 8–9). Patent Owner does not dispute
`Petitioner’s showing with respect to the preamble. See generally PO Resp.
`Claim 1 further recites “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.” Petitioner contends,
`and we agree, that Chambers describes transmitting a request to a server
`(stationary server) to allocate an IP address to use in a data exchange session
`(chat session) with a participating mobile device (invitee’s phone). Pet. 40
`(citing Ex. 1006 ¶ 29, Fig. 2 (step 46); Ex. 1002 ¶ 87). Petitioner further
`contends, and we agree, that RSIP describes an RSIP Host transmitting a
`request to an RSIP Server to allocate a network address and port associated
`with the server (public IP address and port of RSIP Server) to use in a data
`exchange session with participating devices. Id. at 40–41, 48 (citing
`Ex. 1013, 5, 8–10, 16–17, 22, 27–30, 36–39, 49–51; Ex. 1002 ¶¶ 87–89,
`105). In essence, Petitioner proposes replacing Chambers’s server with the
`RSIP Server. Id. at 41. Notwithstanding Patent Owner’s arguments that the
`RSIP Server does not allocate a network address and port associated with the
`server, which we address below, we are persuaded that Petitioner has shown,
`by a preponderance of evidence that Chambers combined with RSIP meets
`this limitation.
`Patent Owner argues that “neither Chambers nor RSIP discloses the
`required request from a mobile device to allocate a network address and port
`associated with the server.” PO Resp. 8–9 (emphasis in original).
`Although Patent Owner agrees that RSIP describes that the RSIP Server
`controls its own local addresses and ports, Patent Owner argues that such
`description does not mean that the RSIP Server receives a request and
`
`14
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`allocates a network address and port associated with the RSIP Server for
`sending to other devices. Id. at 10. Patent Owner further argues that RSIP
`describes that the ASSIGN_RESPONSE_RSAP-IP13 message is used by an
`RSIP Server to deliver parameter assignments to an RSIP Host, but such
`description “does not specify whether the parameters refer to server ports or
`local ports of the mobile devices.” Id. Patent Owner further argues,
`referencing pages 12–14 of its Preliminary Response14, that the descriptions
`related to the ASSIGN_REQUEST_RSAP-IP message indicates that such
`message “contains two address and port 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.” Id. at 10–11 (emphasis in original); see also Sur-reply 12.
`Patent Owner argues that a person having ordinary skill in the art “would
`understand that ‘local’ used in RSIP refers to the particular device being
`discussed.” Sur-reply 15. We are not persuaded by Patent Owner’s
`arguments.
`
`
`13 Petitioner alleges an RSIP Host requests an IP address and port number
`from an RSIP Server by sending an ASSIGN_REQUEST_RSAP-IP
`message to the RSIP Server, and receives the requested IP address and port
`number from the RSIP Server in an ASSIGN_RESPONSE_RSAP-IP
`message. See Pet. 40–42.
`14 To the extent that Patent Owner is attempting to incorporate by reference
`arguments made in the Preliminary Response, such incorporation is
`prohibited. 37 C.F.R. § 42.6(a)(3) (2018) (“[a]rguments must not be
`incorporated by reference from one document into another document”). We
`decline to consider whatever Patent Owner considers is “incorporated” from
`its Preliminary Response as if it were a part of Patent Owner’s Response or
`Sur-reply, but only consider arguments substantively presented in Patent
`Owner’s Response and Sur-reply. See Paper 8, 7.
`
`15
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`RSIP describes, under the header “RSAP-IP: Realm Specific Address
`IP and Port IP,” that RSAP-IP is an RSIP method in which each RSIP host is
`allocated an IP address and some number of per-address unique ports from
`the public realm. Ex. 1013, 9; see also id. at 8 (defining an RSIP Host as a
`host that acquires publicly unique parameters from an RSIP Server)). RSIP
`further describes that an RSIP Gateway “must maintain [a] state for all RSIP
`hosts and their assigned resources,” and under the header “RSAP-IP State,”
`indicates the minimum state the RSIP Gateway MUST maintain is each
`RSIP Host’s private address, assigned public address(es), and assigned
`port(s) per address. Id. at 14 (emphases added).
`The RSIP Server connects the public and private realms and contains
`interfaces to both. Id. at 10. RSIP refers to the private realm as using
`private IP addresses from the ranges (10.0.0.0/8, 172.16.0.0/12,
`192.168.0.0/16). Id. at 8; see also Ex. 1017, 4 (indicating the Internet
`Assigned Numbers Authority (IANA) has reserved three blocks of the IP
`address space for private internets). RSIP further describes that 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. RSIP also describes a “resource” as a way
`to refer to an item that an “RSIP host leases from an RSIP gateway; e.g., an
`address or port.” Id. at 9. In light of such descriptions, we find that the
`examples spanning RSIP pages 49–51 (discussed in detail below) support
`Petitioner’s contention that the RSIP Host transmits a request to an RSIP
`Server to allocate a network address and port associated with the server
`(public IP address and port of RSIP Server) to use in a data exchange session
`with participating devices. Pet. 40–41, 48 (citing Ex. 1013, 5, 8–10, 16–17,
`22, 27–30, 36–39, 49–51; Ex. 1002 ¶¶ 87–89, 105).
`
`16
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`Patent Owner does not contest that RSIP describes that the RSIP
`Server has the ability to explicitly control (e.g., allocate) which local
`addresses and ports are used to communicate with remote addresses and
`ports (PO Resp. 10) and that the local addresses and ports referred to on
`page 12 of RSIP are the RSIP Server’s “own local addresses and ports.” Id.
`at 10. Rather, Patent Owner contends that RSIP’s description of the “local”
`addresses and ports returned by an RSIP server in an
`ASSIGN_RESPONSE_RSAP-IP message has not been shown to be of the
`RSIP Server, but rather are those of “the mobile devices.” Id.
`The pertinent portion from RSIP that Patent Owner refers to is
`reproduced below:
`C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1,
`Address (local) = 0, Ports (local) = 4-0, Address (remote) = 0,
`Ports (remote) = 0, Lease Time = 3600)
`
`The host requests an address and four ports to use with it, but
`doesn’t care which address or ports are assigned. The host does
`not specify the remote address or ports either. The host suggests
`a lease time of 3600 seconds.
`
` S
`
` --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind
`ID = 1, Address (local) = 149.112.240.156, Ports (local) = 4-
`1234, Address (remote) = 0, Ports (remote) = 0, Lease Time =
`1800, Tunnel Type = IP-IP)
`
`The gateway responds by indicating that a bind ID of 1 has been
`assigned to IP address 149.112.240.156 with ports 1234-1237.
`Any remote host may be communicated with, using any remote
`port number. The lease time has been assigned to be 1800
`seconds, and the tunnel type is confirmed to be IP-IP.
`
`The host is now able to communicate with any host on the public
`network using these resources.
`
`17
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`Ex. 1013, 50. RSIP further describes an example where the host requests
`eight more particular ports for use with RSAP-IP with the same address. Id.
`at 51. The gateway grants the request with the same address of
`149.112.240.156, but with a different set of ports. Id. We agree with
`Petitioner that these described RSIP examples establish that the “local
`address and ports” referred to in the description of the requests and
`responses are the public IP address and ports of the RSIP Server. Pet. Reply
`10. In particular, we give substantial weight to Dr. Houh’s testimony that
`the “public IP address [local] 149.112.240.156 is not a private address of the
`host.” Ex. 1025 ¶ 8 (citing Ex. 1013, 8).15 Specifically, RSIP defines the
`private addresses in the host’s private address realm, which do not include
`address 149.112.240.156. Ex. 1013, 8; see also Ex. 1017, 4. This evidence
`supports a finding that when RSIP refers to “local” address and ports it is
`describing the IP address and ports that are the public IP address and ports
`
`
`15 We disagree with Patent Owner that Petitioner’s Reply and Dr. Houh’s
`Reply Declaration (Ex. 1025) are improper. Sur-reply 10–11, 13–14.
`Petitioners are not prohibited from relying on new evidence and arguments
`in a reply, if the evidence and arguments are responsive to arguments made
`in a patent owner response. See 37 C.F.R. 42.23(b); Consolidated Trial
`Practice Guide, 73 (available at
`https://www.uspto.gov/TrialPracticeGuideConsolidated). Here, Petitioner
`could not have anticipated Patent Owner’s unfounded assertion that RSIP’s
`reference to “local” must be construed in relation to the particular device
`that is being discussed. PO Rep. 10 (arguing about “local ports of the
`mobile device” when RSIP never describes “local ports of the mobile
`devices”); Sur-reply 12. We determine that Petitioner’s Reply and
`Dr. Houh’s Reply Declaration (Ex. 1025) are proper and wholly responsive
`to arguments Patent Owner makes. Moreover, Patent Owner could have
`cross-examined Dr. Houh, but did not do so at any point in the trial. Nor did
`Patent Owner request to submit new testimony in support of its Sur-reply.
`
`
`18
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`(resources) associated with the RSIP Server. Id.; Pet. Reply 8 ((“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’”) (citing Ex. 1013, 8–10; Pet.
`40–41; Ex. 1002 ¶¶ 88–92)); see also Ex. 1025 ¶ 7.
`
`On the other hand, Patent Owner directs attention to “9.8.1” of RSIP
`in support of its argument that a person having ordinary skill in the art
`“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.” Sur-reply 12. Patent Owner does
`not direct us to where in RSIP there is support for the assertion that “local”
`refers to the particular device that is being described. The section to which
`we are directed does not so state. Rather, the section that Patent Owner
`argues supports its position describes the ASSIGN_REQUEST_RSAP-IP
`message as a message used by an RSIP host to request “resources” to use
`with RSAP-IP. Ex. 1013, 27. Although the message does include “local”
`address and port fields, RSIP indicates these fields are used by an RSIP Host
`to request a “local address” and a “local port” from the RSIP Server. Id. at
`28 (“An RSIP host may request a particular local address by placing that
`address in the value field of the first address parameter. The RSIP host may
`request particular local ports by placing them in the first port parameter.”
`(emphases added)). If the RSIP Server cannot allocate the requested “local
`address” and “local port” to the RSIP Host (e.g., because they are being
`used), the RSIP Server MUST return an error message. Id. at 29 (“If the
`RSIP gateway cannot allocate a requested address / port tuple because it is in
`use, the RSIP gateway MUST respond with an ERROR_RESPONSE
`containing the LOCAL_ADDRPORT_INUSE error.”). As explained above,
`
`19
`
`

`

`IPR2019-00701
`Patent 8,018,877 B2
`
`
`RSIP defines a resource as a “way to refer to an item that an RSIP host
`leases from an RSIP gateway; e.g., an address or port.” Id. at 9. Moreover,
`RSIP describes RSAP-IP as an RSIP method in which each RSIP host is
`allocated an IP address and unique ports from the public realm. Id. The
`RSIP Server connects the public and private realms and contains interfaces
`to both. Id. at 10.
`When read in a reasonable light, we find that RSIP’s description of
`the RSAP-IP message from the RSIP host specifying “the local address and
`port(s) that will be used” (id. at 27) refers to the public address and ports of
`the RSIP Server as we explain above. We give little to no weight to Patent
`Owner’s argument that the term “local” must be construed in relation to the
`particular device that is being discussed. Sur-reply 12. Patent Owner directs
`us to no evidence in support of its assertions as to what a person having
`ordinary skill in the art would have known at the time of the invention. See
`Estee Lauder Inc. v. L'Oreal, S.A., 129 F.3d 588, 595 (Fed. Cir. 1997)
`(argument of counsel cannot take the place of evidence lacking in the
`record). For all of the above reasons, we are persuaded that the combination
`of Chambers and RSIP meets “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.”
`Petitioner provides sufficient reasons to combine Chambers and RSIP.
`Pet. 35–38. For example, Petitioner explains, and we agree, that it would
`have been obvious to a person having ordinary skill in the art to add RSIP’s
`NAT traversal