Uniloc 2017 LLC

Patent Trials and Appeals Board

Aug 17, 2020

IPR2019-00700 (P.T.A.B. Aug. 17, 2020)

Trials@uspto.gov Paper 17
571-272-7822 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-00700
Patent 8,406,116 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-00700
Patent 8,406,116 B2

2
I. INTRODUCTION
Apple Inc. (“Petitioner”) filed a Petition for inter partes review of
claims 1–20 of U.S. Patent No. 8,406,116 B2 (Ex. 1001, “the ’116 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. 17 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 ’116 patent are
unpatentable.
IPR2019-00700
Patent 8,406,116 B2

3
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-00701 (U.S.
Patent No. 8,018,877 B2) and IPR2019-00702 (U.S. Patent No. 7,969,925
B2). Pet. 1–2.
B. The ’116 Patent1
The ’116 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:39–44), or the failure to allow for real-time
communication between more than two mobile devices. Id. at 1:66–2:5.
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 ’116 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 ’116 patent.
IPR2019-00700
Patent 8,406,116 B2

4

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
IPR2019-00700
Patent 8,406,116 B2

5
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 server, having a publically accessible network address,
opens and listens for mobile device connection requests on a well-known
port. Id. at 4:40–51. After receiving a connection request from an initiating
mobile device, the server establishes a connection with the initiating mobile
IPR2019-00700
Patent 8,406,116 B2

6
device 220. Id. at 4:60–63. The server also allocates and opens a specific
network port number for the IM session and transmits this information to the
initiating mobile device 230. Id. at 4:64–66. Initiating mobile device 230
sends the server’s network address and port number in an invitation message
to other mobile devices through a page-mode messaging service such as
SMS. Id. at 5:3–9. 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:16–21. 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–31.
C. Illustrative Claims
Petitioner challenges claims 1–20 of the ’116 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.
Claims 12 and 15 are reproduced below:
1. A method of initiating a data exchange session
among mobile devices, the method comprising:
receiving, at a server, a request from an initiating mobile
device to allocate a session identifier to use in a data exchange
session with a participating mobile device, wherein the session
identifier comprises a network port number of the server;
transmitting, from the server, the session identifier to the
initiating mobile device, wherein the initiating mobile device
uses a page-mode messaging service to assist in communicating
the session identifier to the participating mobile device and

2 Independent claims 1 and 8 have similar limitations, and for purposes of
this decision, claim 1 is illustrative of claim 8.
IPR2019-00700
Patent 8,406,116 B2

7
wherein the page-mode messaging service utilizes a unique
identifier to locate the participating mobile device;
establishing, at the server, connections with the initiating
mobile device and the participating mobile device based on the
session identifier; and
facilitating, at the server, the data exchange session
between the initiating mobile device and the participating mobile
device.
Ex. 1001, 8:20–40.
15. A server configured to facilitate a data exchange
session among mobile devices, the server comprising:
an input port to receive a request from an initiating mobile
device to allocate a session identifier to use in a data exchange
session with a participating mobile device, wherein the session
identifier comprises a network port number of the server; and
an output port to transmit the session identifier to the
initiating mobile device, wherein the initiating mobile device
uses a page-mode messaging service to assist in communicating
the session identifier to the participating mobile device and
wherein the page-mode messaging service utilizes a unique
identifier to locate the participating mobile device; and
a computer for:
establishing connections with the initiating mobile device
and the participating mobile device based on the session
identifier; and
facilitating the data exchange session between the
initiating mobile device and the participating mobile device.
Ex. 1001, 9:36–10:18.
IPR2019-00700
Patent 8,406,116 B2

8
D. Instituted Grounds of Unpatentability
We instituted trial based on all asserted grounds of unpatentability
under 35 U.S.C.3 as follows (Dec. 7–8, 30):
Claim(s) Challenged 35 U.S.C. § Reference(s)/Basis
1–20 103(a) Kirmse4, Chambers5
1–20 103(a) Chambers, RSIP6
1–3, 5–10, 12–17, 19, 20 103(a) Cordenier7, TURN8
II. ANALYSIS
A. Principles of Law
To prevail in its challenges to Patent Owner’s claims, Petitioner must
demonstrate by a preponderance of the evidence9 that the claims are
unpatentable. 35 U.S.C. § 316(e) (2012); 37 C.F.R. § 42.1(d) (2018). A

3 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 ’116
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.
4 U.S. Patent No. 6,669,125 B2, issued Mar. 2, 2004 (Ex. 1005, “Kirmse”).
5 U.S. Patent Application Pub. No. U.S. 2003/0142654 A1, published July
31, 2003 (Ex. 1006, “Chambers”).
6 Realm Specific IP: Protocol Specification, RFC 3103, published by IETF
no later than Oct. 2001, and Declaration of Sandy Ginoza (Ex. 1013,
“RSIP”).
7 European Patent Application Publication No. EP 1 385 323 A1, published
Jan. 28, 2004 (Ex. 1007, “Cordenier”).
8 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”).
9 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).
IPR2019-00700
Patent 8,406,116 B2

9
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.10 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. 11
(citing Ex. 1002 ¶ 42). Dr. Houh further testifies that additional graduate
education could substitute for professional experience, and significant

10 Patent Owner does not present any objective evidence of nonobviousness
as to the challenged claims.
IPR2019-00700
Patent 8,406,116 B2

10
experience in the field could substitute for formal education. Ex. 1002 ¶ 42.
Patent Owner does not propose an alternative assessment. PO Resp. 3–4.
We adopt Dr. Houh’s assessment of a person with ordinary skill in the
art as it is consistent with the ’116 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
IPR2019-00700
Patent 8,406,116 B2

11
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. 37–53. In support of its
showing, Petitioner relies upon the declaration of Dr. Houh. Id. (citing
Ex. 1002 ¶¶ 82–114).
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.
IPR2019-00700
Patent 8,406,116 B2

12

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.
IPR2019-00700
Patent 8,406,116 B2

13
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.11 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:

11 Petitioner cites to the page numbers added by Petitioner in the lowest right
corner. We cite to the same.
IPR2019-00700
Patent 8,406,116 B2

14
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.12
3. Discussion
Claim 1 recites a “method of initiating a data exchange session among
mobile devices.”13 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

12 Petitioner refers to the RSIP Gateway running an RSIP Server,
collectively as the “RSIP Server.” Pet. 38. Patent Owner appears to do the
same (PO Resp. 10) as do we.
13 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.
IPR2019-00700
Patent 8,406,116 B2

15
Server. Pet. 42 (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 “receiving, at a server, a request from an
initiating mobile device to allocate a session identifier to use in a data
exchange session with a participating mobile device, wherein the session
identifier comprises a network port number of the server.” Petitioner
contends, and we agree, that Chambers describes a server (stationary server)
receiving a request from an initiating mobile device (inviter’s phone) to
allocate an IP address to use in a data exchange session (chat session) with a
participating mobile device (invitee’s phone). Pet. 43 (citing Ex. 1006 ¶ 29,
Fig. 2 (step 46); Ex. 1002 ¶ 93). Petitioner further contends, and we agree,
that RSIP describes that an RSIP Server receives a request from an initiating
device (RSIP Host) to allocate a session identifier (public IP address and
port number of the RSIP Server) to use in a data exchange session with
participating devices. Id. at 43–44, 53 (citing Ex. 1013, 5, 8–10, 16–17, 22,
27–30, 36–39, 45, 49–51; Ex. 1002 ¶¶ 93–95, 114). In essence, Petitioner
proposes replacing Chambers’s server with the RSIP Server. Id. at 44.
Notwithstanding Patent Owner’s arguments that the RSIP Server does not
allocate a session identifier including a network port number of the RSIP
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 disclose the
required receiving at a server, a request from a mobile device to allocate a
session identifier, comprising a network port number of the server.” PO
Resp. 8–9 (emphasis in original). Although Patent Owner agrees that RSIP
IPR2019-00700
Patent 8,406,116 B2

16
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 allocates a session identifier comprising the RSIP Server’s addresses
and ports to other devices. Id. at 10. Patent Owner further argues that RSIP
describes that the ASSIGN_RESPONSE_RSAP-IP14 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–17 of its Preliminary Response15, that the descriptions
related to the ASSIGN_REQUEST_RSAP-IP message indicate 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. (emphasis in original); see also Sur-reply 10–11. Patent
Owner argues that “[n]othing in RSIP would cause a POSITA to interpret
‘local’ to mean anything other than a port of the particular device being

14 Petitioner alleges an RSIP Host requests a session identifier (i.e., 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. 43, 45.
15 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 fully consider arguments substantively presented in Patent
Owner’s Response and Sur-reply. See Paper 8, 7.
IPR2019-00700
Patent 8,406,116 B2

17
discussed.” Sur-reply 13. We are not persuaded by Patent Owner’s
arguments.
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, 8 (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 Server receives a request from an
initiating device (RSIP Host) to allocate a session identifier (public IP
address and port number of the RSIP Server) to use in a data exchange
IPR2019-00700
Patent 8,406,116 B2

18
session with participating devices. Pet. 43–44, 53 (citing Ex. 1013, 5, 8–10,
16–17, 22, 27–30, 36–39, 45, 49–51; Ex. 1002 ¶¶ 93–95, 114).
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. 12) 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 those 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.

IPR2019-00700
Patent 8,406,116 B2

19
The host is now able to communicate with any host on the public
network using these resources.
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).16 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, 8. This evidence

16 We disagree with Patent Owner that Petitioner’s Reply and Dr. Houh’s
Reply Declaration (Ex. 1025) are improper. Sur-reply 8–9, 11–12.
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 10. 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.

IPR2019-00700
Patent 8,406,116 B2

20
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
(resources) of the RSIP Server. Id.; Pet. Reply 8–9 ((“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. 43–45;
Ex. 1002 ¶¶ 94–98)); 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 10. 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
IPR2019-00700
Patent 8,406,116 B2

21
use, the RSIP gateway MUST respond with an ERROR_RESPONSE
containing the LOCAL_ADDRPORT_INUSE error.”). As explained above,
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 10. 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 “receiving, at a server, a request from an
initiating mobile device to allocate a session identifier to use in a data
exchange session with a participating mobile device, wherein the session
identifier comprises a network port number of the server.”
Petitioner provides sufficient reasons to combine Chambers and RSIP.
Pet. 38–41. 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 techniques to Chambers to obtain the benefits of using less
IPR2019-00700
Patent 8,406,116 B2

22
scarce private IP addresses. Id. at 39 (citing Ex. 1006 ¶¶ 27, 36; Ex. 1013, 7;
Ex. 1002 ¶ 87). Petitioner argues that adding NAT traversal functionality
like RSIP was within the skill of a person having ordinary skill in the art. Id.
at 40. Petitioner argues, and we agree, that a person having ordinary skill in
the art would have had a reasonable expectation of success in adding RSIP’s
NAT traversal functionality to Chambers, because the initiating phone of
Chambers would only need a slight software modification to request an IP
address and port number from the RSIP Server. Id. at 40–41 (citing Ex.
1002 ¶ 90). We determine that it would have been obvious to combine
Chambers with RSIP for the reasons Petitioner provides. Patent Owner does
not dispute Petitioner’s showing with respect to the reasons for combining
Chambers with RSIP. See generally PO Resp.
Claim 1 further recites “transmitting, from the server, the session
identifier to the initiating mobile device.” Petitioner contends, and we find,
that Chambers describes transmitting from the stationary server the
requested IP address to the initiating mobile phone. Pet. 44 (citing Ex. 1006
¶ 29, Fig. 2 (step 46); Ex. 1002 ¶ 96). Petitioner further contends, and we
agree, that RSIP describes transmitting from the RSIP Server the session
identifier, comprising an IP address and port number, to the RSIP Host. Id.
at 45 (citing Ex. 1013, 5, 10, 16–17, 30–31, 45, 49–51; Ex. 1002 ¶ 97). We
agree with Petitioner that it would have been obvious to a person having
ordinary skill in the art to combine Chambers and RSIP such that the RSIP
Server transmits the session identifier (the requested public IP address and
port in ASSIGN_RESPONSE_RSIP-IP) to the initiating mobile device. Id.
(citing Ex. 1002 ¶ 98). Patent Owner does not dispute Petitioner’s showing
with respect to this limitation. See generally PO Resp.
IPR2019-00700
Patent 8,406,116 B2

23
Claim 1 also recites “wherein the initiating mobile device uses a page-
mode messaging service to assist in communicating the session identifier to
the participating mobile device and wherein the page-mode messaging
service utilizes a unique identifier to locate the participating mobile device.”
Petitioner contends, and we find, that Chambers describes that the initiating
mobile phone uses a page-mode messaging service (SMS) to assist in
communicating the session identifier to the participating mobile phones,
where the SMS utilizes a unique identifier (telephone number) to locate the
participating mobile phones. Pet. 45–46 (citing Ex. 1006, Fig. 2 (step 48),
¶¶ 28, 30–32; Ex. 1002 ¶ 99). Petitioner further contends, and we agree, that
RSIP “teaches that the RSIP host (initiating device) may use the session
identifier (the requested public IP address and port) to communicate with
remote hosts without explicitly notifying the gateway.” Id. at 46 (citing Ex.
1013, 13; Ex. 1002 ¶ 100). We agree with Petitioner that it would have been
obvious to a person having ordinary skill in the art to combine Chambers
and RSIP such that the Chambers SMS invitation message includes the
public IP address and port number of the RSIP Server, so that the responding
mobile phones would be able to traverse the NAT by responding through the
RSIP Server. Id. (citing Ex. 1002 ¶ 101). Patent Owner does not dispute
Petitioner’s showing with respect to this limitation. See generally PO Resp.
Claim 1 further recites “establishing, at the server, connections with
the initiating mobile device and the participating mobile device based on the
session identifier.” Petitioner contends, and we find, that Chambers
describes establishing a connection with the initiating mobile device
(inviter’s mobile phone) and the participating mobile device based on the
session identifier (temporary IP address), when the participating mobile
phone responds with an IP message to the IP address provided in the SMS
IPR2019-00700
Patent 8,406,116 B2

24
invitation. Pet. 47 (citing Ex. 1006 ¶¶ 26–39, Figs. 1–2; Ex. 1002 ¶ 102).
Petitioner further argues, and we agree, that RSIP describes establishing at
the RSIP Server connections with the RSIP Host and the participating device
(Remote Host) based on the session identifier (public IP and port number),
when the RSIP Server maps the allocated resources to the RSIP Host and
Remote Host. Id. at 47–48 (citing Ex. 1013, 10–12, 14, 37; Ex. 1002 ¶ 103).
We agree with Petitioner that it would have been obvious to a person having
ordinary skill in the art to combine Chambers and RSIP to provide for
establishing at the RSIP Server a connection with the initiating mobile
device and the participating mobile device based on the session identifier
when the responding mobile phones reply to the initiating mobile phone
through the RSIP Server. Id. at 48–49 (citing Ex. 1002 ¶ 105). Patent
Owner does not dispute Petitioner’s showing with respect to this limitation.
See generally PO Resp.
Claim 1 further recites “facilitating, at the server, the data exchange
session between the initiating mobile device and the participating mobile
device.” Petitioner contends, and we agree, that Chambers describes a data
exchange session between the initiating and participating mobile devices.
Pet. 49 (citing Ex. 1006, Fig. 2 (steps 62, 68), ¶¶ 14–15, 40–46;
Ex. 1002 ¶ 106). Petitioner further contends, and we agree, that RSIP
describes facilitating at the RSIP Server a data exchange session between an
RSIP Host and a Remote Host. Id. at 49–50 (citing Ex. 1013, 10–12, 37;
Ex. 1002 ¶ 107). We agree with Petitioner that it would have been obvious
to a person having ordinary skill in the art to combine Chambers and RSIP
to provide for facilitating at the RSIP Server the data exchange session
between the initiating mobile device and the participating mobile devices.
IPR2019-00700
Patent 8,406,116 B2

25
Id. at 50 (citing Ex. 1002 ¶ 108). Patent Owner does not dispute Petitioner’s
showing with respect to this limitation. See generally PO Resp.
Independent claims 8 and 15 are similar to claim 1. Petitioner’s
showings for claims 8 and 15 are nearly the same as that for claim 1, while
sufficiently accounting for differences between claims 8 and 15 and claim 1.
See Pet. 37–50. Patent Owner’s arguments for claims 8 and 15 are the same
as its arguments for claim 1, which we have addressed above. Accordingly,
for the reasons given above, having considered Petitioner’s and Patent
Owner’s arguments and evidence, we determine that Petitioner has shown by
a preponderance of the evidence that claims 1, 8, and 15 of the ’116 patent
would have been obvious over Chambers and RSIP.
Claims 2, 9, and 16 depend from claims 1, 8, and 15 respectively and
include “wherein the page-mode messaging service may be utilized to
transmit page-mode messages to devices for purposes unrelated to
participating in the data exchange session.” Petitioner relies on Chambers to
meet the limitation. Id. at 50 (citing showing under Ground 1; Ex. 1002
¶ 109). In particular, Petitioner contends, and we agree, that Chambers
describes that the page-mode messaging service (SMS) may be utilized to
transmit an SMS message to devices for purposes unrelated to participating
in the chat session, such as by displaying the SMS message. Id. at 34 (citing
Ex. 1006 ¶¶ 3–7). Patent Owner does not make separate arguments with
respect to claims 2, 9, and 16. PO Resp. 15. We are persuaded by
Petitioner’s showing, which we adopt, that claims 2, 9, and 16 would have
been obvious over Chambers and RSIP.
Claims 3, 10, and 17 depend from claims 2, 9, and 16 respectively and
include “wherein the page-mode messaging service transmits a page-mode
message to the participating mobile device that is encoded to be recognized
IPR2019-00700
Patent 8,406,116 B2

26
by software on the participating mobile device configured to participate in
the data exchange session.” Petitioner relies on Chambers to meet the
limitation. Pet. 50–51. In particular, Petitioner contends that Chambers
describes that the page-mode messaging service (SMS) transmits a page-
mode message to the participating mobile device that is encoded to be
recognized by software (the SMS software) on the participating device
configured to participate in the data exchange session (the invitee’s wireless
phone). Id. (citing Ex. 1006, Fig. 2 (steps 50–56), ¶¶ 3–7, 23, 33–37).
Alternatively, Petitioner argues that it would have been obvious to a person
having ordinary skill in the art to encode the messages to be recognized by
software, such as a standard SMS application. Id. at 51 (citing Ex. 1002 ¶
110). Patent Owner does not make separate arguments with respect to
claims 3, 10, and 17. PO Resp. 15. We are persuaded by Petitioner’s
showing, which we adopt, that claims 3, 10, and 17 would have been
obvious over Chambers and RSIP.
Claims 4, 11, and 18 depend from claims 1, 8, and 15 respectively and
include “wherein additional devices are invited to participate in the data
exchange session.” Petitioner contends, and we agree, that Chambers
describes that additional devices are invited to participate in the data
exchange session (chat session). Pet. 51 (citing Ex. 1006, Figs. 1–2, ¶¶ 26–
39, claim 17). Patent Owner does not make separate arguments with respect
to claims 4, 11, and 18. PO Resp. 15. We are persuaded by Petitioner’s
showing, which we adopt, that claims 4, 11, and 18 would have been
obvious over Chambers and RSIP.
Claims 5, 12, and 19 depend from claims 1, 8, and 15 respectively and
include “wherein the server is a non-mobile device.” Petitioner contends
that Chambers describes that the initiating mobile device requests an IP
IPR2019-00700
Patent 8,406,116 B2

27
address from a stationary (non-mobile) server. Pet. 52 (citing Ex. 1006
¶ 29). Petitioner further contends, and we agree, that it would have been
obvious to implement the RSIP Server as a stationary server as taught by
Chambers, because it would have been easier, cheaper, and provided high
reliability required of a server performing NAT translation for numerous
hosts. Id. (citing Ex. 1002 ¶ 112). Patent Owner does not make separate
arguments with respect to claims 5, 12, and 19. PO Resp. 15. We are
persuaded by Petitioner’s showing, which we adopt, that claims 5, 12, and
19 would have been obvious over Chambers and RSIP.
Claims 6, 13, and 20 depend from claims 1, 8, and 15 respectively and
include “wherein the unique identifier utilized by the page-mode messaging
service is associated with a telephone number of the participating mobile
device.” Petitioner relies on Chambers to meet the limitation. Pet. 52
(citing showing under Ground 1, claim 6; Ex. 1002 ¶ 113). In particular,
Petitioner contends, and we agree, that Chambers describes that the unique
identifier utilized by the page-mode messaging service is associated with a
telephone number of the participating mobile device, because it is the
telephone number of the recipient. Id. at 36–37 (citing Ex. 1006 ¶ 4). Patent
Owner does not make separate arguments with respect to claims 6, 13, and
20. PO Resp. 15. We are persuaded by Petitioner’s showing, which we
adopt, that claims 6, 13, and 20 would have been obvious over Chambers
and RSIP.
Claims 7 and 14 depend from claims 1 and 8 respectively and include
“wherein the session identifier further comprises an IP address.” Petitioner
contends, and we agree, that Chambers and RSIP each disclose that the
session identifier further comprises an IP address. Pet. 53 (citing Ex. 1006
¶ 30; Ex. 1013, 49–51; Ex. 1002 ¶ 114). Patent Owner does not make
IPR2019-00700
Patent 8,406,116 B2

28
separate arguments with respect to claims 7 and 14. PO Resp. 15. We are
persuaded by Petitioner’s showing, which we adopt, that claims 7 and 14
would have been obvious over Chambers and RSIP.
In sum, having considered Petitioner’s and Patent Owner’s arguments
and evidence, we determine that Petitioner has shown by a preponderance of
the evidence that claims 1–20 of the ’116 patent would have been obvious
over Chambers and RSIP.
E. Constitutional Challenge to Inter Partes Review
Patent Owner contends that the Board lacks constitutional power to
issue a Final Written Decision in this proceeding under the Appointments
Clause of the U.S. Constitution. PO Resp. 15–16; Sur-reply 20. We decline
to consider Patent Owner’s constitutional challenge, as the issue has been
addressed by the Federal Circuit in Arthrex, Inc. v. Smith & Nephew, Inc.,
941 F.3d 1320, 1328 (Fed. Cir. 2019).
F. Remaining Grounds Challenging
Claims 1–20 of the ’116 Patent
For the reasons discussed above, Petitioner has shown, by a
preponderance of the evidence, that claims 1–20 of the ’116 patent are
unpatentable as obvious over Chambers and RSIP. In addressing this
ground, we have addressed all of the challenged claims. See 35 U.S.C.
§ 318(a) (requiring the Board to “issue a final written decision with respect
to the patentability of any patent claim challenged by the petitioner and any
new claim added under section 316(d)”); see also SAS Inst. Inc. v. Iancu,
138 S. Ct. 1348, 1359 (2018) (holding that a petitioner “is entitled to a final
written decision addressing all of the claims it has
challenged”). Accordingly, we need not and do not decide whether
IPR2019-00700
Patent 8,406,116 B2

29
Petitioner has shown by a preponderance of the evidence that (1) claims 1–
20 are unpatentable as obvious over Kirmse and Chambers, and (2) claims
1–3, 5–10, 12–17, 19, and 20 are unpatentable as obvious over Cordenier
and TURN. Cf. In re Gleave, 560 F.3d 1331, 1338 (Fed. Cir. 2009) (not
reaching other grounds of unpatentability after affirming the anticipation
ground); see also Beloit Corp. v. Valmet Oy, 742 F.2d 1421, 1423 (Fed. Cir.
1984) (holding that once a dispositive issue is decided, there is no need to
decide other issues).
III. CONCLUSION17
For the foregoing reasons, we determine that Petitioner has shown by
a preponderance of the evidence that claims 1–20 of the ’116 patent are
unpatentable, as summarized in the following table:

Claims 35 U.S.C. §
Reference(s)/
Basis
Claims
Shown
Unpatentable
Claims Not
Shown
Unpatentable
1–20 103(a)18 Kirmse,
Chambers

17 Should Patent Owner wish to pursue amendment of the challenged claims
in a reissue or reexamination proceeding subsequent to the issuance of this
Decision, we draw Patent Owner’s attention to the April 2019 Notice
Regarding Options for Amendments by Patent Owner Through Reissue or
Reexamination During a Pending AIA Trial Proceeding. See 84 Fed. Reg.
16654 (Apr. 22, 2019). If Patent Owner chooses to file a reissue application
or a request for reexamination of the challenged patent, we remind Patent
Owner of its continuing obligation to notify the Board of any such related
matters in updated mandatory notices. See 37 C.F.R. § 42.8(a)(3), (b)(2).
18 As explained immediately above, we need not and do not decide whether
Petitioner has shown by a preponderance of the evidence that claims 1–20
also would have been obvious based on the remaining grounds not addressed
in this Decision.
IPR2019-00700
Patent 8,406,116 B2

30
1–20 103(a) Chambers,
RSIP
1–20
1–3, 5–10,
12–17, 19,
20
103(a)
Cordenier,
TURN

Overall
Outcome
1–20

IV. ORDER
Accordingly, it is:
ORDERED that claims 1–20 of the ’116 patent have been shown to be
unpatentable; and
FURTHER ORDERED that, because this is a Final Written Decision,
parties to the proceeding seeking judicial review of the Decision must
comply with the notice and service requirements of 37 C.F.R. § 90.2.

IPR2019-00700
Patent 8,406,116 B2

31
PETITIONER:
Brian Erickson
James M. Heintz
DLA PIPER LLP
brian.erickson@dlapiper.com
jim.heintz@dlapiper.com
PATENT OWNER:
Ryan Loveless
Brett Mangrum
James Etheridge
Jeffrey Huang
ETHERIDGE LAW GROUP
ryan@etheridgelaw.com
brett@etheridgelaw.com
jim@etheridgelaw.com
jeff@etheridgelaw.com