Trials@uspto.gov
`571.272.7822
`
`
`
`
`
` Paper No. 7
`Entered: August 26, 2019
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`____________
`
`Case 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.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`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.”). Institution of an inter partes review is
`
`authorized by statute when “the information presented in the petition . . . and
`
`any response . . . shows that there is a reasonable likelihood that the
`
`petitioner would prevail with respect to at least 1 of the claims challenged in
`
`the petition.” 35 U.S.C. § 314(a). Upon consideration of the Petition and
`
`Preliminary Response, we conclude the information presented shows that
`
`there is a reasonable likelihood that Petitioner would prevail in establishing
`
`the unpatentability of at least one of claims 1–20 of the ’116 patent under
`
`35 U.S.C. § 103(a).
`
`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: 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 Patent
`
`The ’116 patent is directed to methods and a server-based architecture
`
`for establishing data exchange between multiple mobile devices. Ex. 1001,
`
`Abstract, 1:23–27. 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
`
`2
`
`

`

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

`

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

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`
`
`
`In Figure 2, the server requires a publically accessible network address, and
`
`as an initial step, the server must be open and listening 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 device 220. Id. at 4:60–63. The server
`
`also opens and allocates 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
`
`5
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`forwarding all messages between participating mobile devices. Id. at 5:20–
`
`31.
`
`C. Illustrative Claim
`
`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 11 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
`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:
`
`
`1 Independent claims 1 and 8 have similar limitations, and for purposes of
`this decision, claim 1 is illustrative of claim 8.
`
`6
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`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.
`
`D. Asserted Grounds of Unpatentability
`
`Petitioner asserts that claims 1–20 are unpatentable based on the
`
`following grounds. Pet. 6:
`
`References
`Kirmse3 and Chambers4
`Chambers and RSIP5
`
`Basis2
`
`§ 103
`
`§ 103
`
`Challenged Claims
`
`1–20
`
`1–20
`
`
`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 ’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.
`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”).
`
`7
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`References
`
`Cordenier6 and TURN7
`
`
`
`Basis2
`
`§ 103
`
`Challenged Claims
`1–3, 5–10, 12–17,
`19, and 20
`
`II. DISCUSSION
`
`A. Claim Construction
`
`In this inter partes review, claims are 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). 37 C.F.R. § 42.100(b) (2019). The claim
`
`construction standard includes construing 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 id.; 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
`
`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).
`
`B. Principles of Law
`
`A 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
`
`
`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
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`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;8 and (4) when in evidence, objective
`
`indicia of nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17–18
`
`(1966).
`
`C. Asserted Obviousness of Claims 1–20 over Kirmse and Chambers
`
`Petitioner contends claims 1–20 are unpatentable under 35 U.S.C.
`
`§ 103(a) as obvious over Kirmse and Chambers. Pet. 17–37. In support of
`
`its showing, Petitioner relies upon the declaration of Dr. Houh. Id. (citing
`
`Ex. 1002 ¶¶ 24–81).
`
`1. Kirmse
`
`Kirmse discloses a game and messenger client-server gaming system,
`
`wherein a game client can be coupled to a messenger client to allow for data
`
`exchange to initiate the joining of a game. Ex. 1005, Abstract. The game
`
`and messenger client-server system comprises a plurality of game clients; a
`
`game server; a plurality of messenger clients; and a messenger server. Id.
`
`
`8 Relying on the testimony of Dr. Henry H. Houh, Petitioner offers an
`assessment as to the level of skill in the art at the time of the ’116 patent.
`Pet. 11 (citing Ex. 1002 ¶ 42). At this time, Patent Owner does not propose
`an alternative assessment. Prelim. Resp. 9. To the extent necessary, and for
`purposes of this Decision, we accept the assessment offered by Petitioner as
`it is consistent with the disclosures in the ’116 patent and the asserted prior
`art.
`
`9
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`In one embodiment, the game client interfaces with the game server, and the
`
`messenger client interfaces with the messenger server. Id. at 4:1–4.
`
`Alternatively, the game client and messenger client can be merged into a
`
`single application, and game and messenger servers can be operated as a
`
`single server. Id. at 4:5–11. Kirmse describes its system as also applicable
`
`to non-game multi-user applications, i.e., other computer or computer users
`
`could be invited to join a multi-user activity other than a game. Id. at 4:14–
`
`17.
`
`Figure 1, reproduced below, illustrates a block diagram of a game-
`
`messenger client-server system:
`
`Figure 1 is a block diagram of a messenger client-server system 10. Id. at
`
`4:33–34. In the client-server system, users connect for online game play by
`
`connecting user computers 12 to a game server 14 via a network 16. Id. at
`
`4:35–37. Additionally, a messenger server 18 is provided so that one or
`
`
`
`10
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`more users can send messages over network 16 to other users. Id. at 4:51–
`
`54.
`
`Shown in Figure 4, and described below, is a flowchart illustrating the
`
`process of an inviter client inviting an invitee into a game and having the
`
`invitee join the game. Id. at 3:32–35. In one embodiment, a player starts a
`
`multiplayer game S1, the game-client connects to the game server S2, which
`
`provides connection details, such as the server’s IP address and port number
`
`to the game client S4. Id. at 7:26–36. The inviter game client creates a
`
`message S5 and sends this message to the messenger client, which sends the
`
`message to the messenger server S6 to forward the message to invite other
`
`players S7. Id. at 7:37–46. The invitee receives the message S8. Id. The
`
`message includes information to join the game, such as the server’s IP
`
`address and port number. Id. If the invitee decides to join the game S9, the
`
`invitee uses the connection information contained in the message S10 and
`
`joins the game S11, whereby the game server connects the invitee as one of
`
`the players S12. Id. at 7:46–53.
`
`11
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`
`Figure 4 shows a flowchart illustrating the process of an inviter client
`
`inviting an invitee into a game and having the invitee join the game.
`
`
`
`2. 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 to a plurality of other users who accept and reply to the invitation
`
`12
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`message to initiate a chat session. Ex. 1006, Abstract. Figure 2 illustrates a
`
`flow diagram of a preferred embodiment of a method of providing a
`
`communication session in accordance with the principles of Chamber’s
`
`invention. Id. at ¶ 26.
`
`Specifically, as illustrated in Figure 2, in a preferred embodiment, a member
`
`list is created 44, after which an IP address for the initiator terminal is
`
`
`
`13
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`requested 46. Id. at ¶¶ 27–29. After the IP address is requested, an
`
`invitation message, in the form of a SMS-message, is sent to the member list
`
`48, and once the SMS-message is received 50, each member can decide
`
`whether to accept the message 52. Id. at ¶¶ 30–33. Upon accepting the
`
`invitation, an IP address is requested 54 and a reply is sent to the invitation
`
`message 56. Id. at ¶¶ 34–35. After receiving the reply 58, the replying
`
`member is marked as active 60, and if the reply is a first reply 61, the chat
`
`session is active 62 and any active member can send data 68 after which the
`
`communication session ends 70. Id. at ¶¶ 37–39, 43, 45. If at step 61, the
`
`reply is not a first reply, then the active member list is updated 64, at which
`
`point the active member list is transmitted 66 and these active members can
`
`send data 68. Id. at ¶¶ 47–48.
`
`3. Discussion
`
`Petitioner contends Kirmse describes a method of initiating a data
`
`exchange session (e.g., online gaming, conferencing, whiteboarding) among
`
`mobile devices (e.g., wireless phones), meeting the preamble of claim 1.
`
`Pet. 18–19 (citing Ex. 1005, 4:33–45, 7:25–8:15, Figs. 1 and 4–5).
`
`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.” Ex. 1001, 8:23–
`
`27. Petitioner contends that Kirmse describes a server (game server) that
`
`receives, over the Internet, a request from an inviter to allocate a session
`
`identifier. Pet. 20, 22 (citing Ex. 1005, Abstract, 4:37–45, 5:21–43, Fig. 4,
`
`steps S2-S3; Ex. 1002 ¶ 57). Petitioner further contends that the session
`
`identifier comprises a network port number of the server, such as the port
`
`number for the online game session. Id. at 22 (citing Ex. 1005, Fig. 4 (step
`
`14
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`S3), Fig. 5, 5:61–65, 7:27–36, 8:1–15, 10:53–11:4, 15:35–42; Ex. 1002
`
`¶ 57).
`
`Patent Owner argues that Kirmse does not disclose the server
`
`receiving, from a mobile device, a request to allocate a session identifier as
`
`claimed. Prelim. Resp. 10–12. Patent Owner argues that there is nothing in
`
`Kirmse that describes a mobile device requesting to allocate a session
`
`identifier because the server serves active games where the session
`
`identifier, such as port number, is already known to the game client. Id.
`
`(citing Ex. 1005, 5:59–65).
`
`Patent Owner’s attorney arguments are unpersuasive. Patent Owner
`
`cites to a passage that describes “[t]he reference to the game being served to
`
`[a] client” is known to a game client. Id. The same passage, however,
`
`indicates that the game client may alternatively obtain the reference to the
`
`game from the server. Ex. 1005, 5:59–65. Moreover, Patent Owner does
`
`not explain why Petitioner’s showing, supported by record evidence, that
`
`steps S2-S3 of Kirmse Figure 4 fails to show the game server receiving the
`
`request from the inviter to allocate a session identifier. Pet. 20–22. For
`
`instance, once the game client connects to a game server to join or start a
`
`game (S2), the game server serves up an active game (S3) and provides (S4)
`
`the inviter with information such as IP address and port number, so the
`
`inviter can play the game. Ex. 1005, 7:29–36. Patent Owner does not
`
`explain in any way why, if the game client allegedly already knows the
`
`identifier to play the game, Kirmse describes the server providing the
`
`identifier. Accordingly, we are not persuaded by Patent Owner’s arguments.
`
`Claim 1 further recites “transmitting, from the server, the session
`
`identifier to the initiating mobile device.” Ex. 1001, 8:28–29. Petitioner
`
`contends, for example, that Kirmse’s description of step S4 (Fig. 4) meets
`
`15
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`the limitation, as the game server serves up the game and provides the
`
`inviter with enough information, such as the IP address and port number, so
`
`the inviter can play the game. Pet. 22 (citing Ex. 1005, 7:27–36, Fig. 4, step
`
`S4).
`
`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.”
`
`Ex. 1001, 8:29–34. Petitioner contends that Kirmse describes the initiating
`
`mobile device (inviter’s mobile phone) uses one of a variety of services to
`
`assist in communicating the session identifier (invocation data including IP
`
`address and port of the game server) to the participating mobile devices
`
`(other players’ mobile phones). Pet. 25 (citing Ex. 1005, 6:21–48, 7:36–45,
`
`8:1–15, 10:52–11:4, 15:35–42, Fig. 2, Fig. 4 (Steps S5–S8), Fig. 5; Ex.
`
`1002 ¶ 63). Petitioner contends that Kirmse teaches that the invitation (from
`
`the inviter to invitee to join the game) could use a messaging service such as
`
`Yahoo! Messenger and a messenger server for routing the message to the
`
`invitee. Id. at 27 (citing Ex. 1005, 4:1–11, 8:45–67, 12:8–10, Fig. 4 (Step
`
`S7, Figs. 11B, 11E). Petitioner relies on Chambers, however, to teach that
`
`invitation messages can be sent between wireless phones to set up multi-user
`
`applications, such as chat, using “a page-mode messaging service” (SMS)
`
`that utilizes a “unique identifier to locate” a mobile device, as claimed. Id.
`
`at 27–28 (citing Ex. 1006 ¶¶ 4, 20, 31, 34–37, Fig. 1; Ex. 1002 ¶ 65).
`
`Petitioner provides reasons, with rational underpinning, to combine Kirmse
`
`and Chambers. Id. at 28–30 (citing multiple passages from Ex. 1002 ¶¶ 66–
`
`70).
`
`16
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`Claim 1 recites “establishing, at the server, connections with the
`
`initiating mobile device and the participating mobile device based on the
`
`session identifier.” Ex. 1001, 8:35–37. Petitioner contends that Kirmse
`
`describes establishing at the game server connections with the initiating
`
`mobile device (inviter’s mobile phone) and the participating mobile device
`
`(invitee’s mobile phone) based on the session identifier (invocation data,
`
`including game server’s IP address and port). Pet. 30 (referring to showing
`
`for elements 1.a and 1.b; Ex. 1005, Fig. 3, Fig. 4 (steps S9–S12), Fig. 7 (step
`
`S203), Fig. 11E, 6:49–7:25, 7:46–53, 8:30–67, 11:44–60, 15:35–44; Ex.
`
`1002 ¶ 71).
`
`Claim 1 further recites “facilitating, at the server, the data exchange
`
`session between the initiating mobile device and the participating mobile
`
`device.” Ex. 1001, 8:38–40. Petitioner contends that Kirmse’s game server
`
`facilitates the data exchange session (online game, whiteboarding, chat, etc.)
`
`between the initiating mobile device (inviter’s wireless phone) and the
`
`participating mobile device (invitee’s wireless phone). Pet. 33 (citing Ex.
`
`1005, 4:10–18, 6:49–7:25, 7:46–53, 9:14–55, 8:30–67, 11:44–60, 15:35–44,
`
`17:35–52, Figs. 3, 4, 7, 10, 11E; Ex. 1002 ¶ 74).
`
`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. 18–33. Patent Owner’s arguments for claims 8 and 15 are the same
`
`as its arguments for claim 1, which we have addressed above. Prelim. Resp.
`
`10–12. We also have reviewed Petitioner’s showing for dependent claims
`
`2–7, 9–14, and 16–20. Id. at 34–37. Patent Owner does not contest those
`
`claims separately. Prelim. Resp. 23.
`
`17
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`Based on the current record before us, we are persuaded by
`
`Petitioner’s showing that the asserted prior art references teach or suggest
`
`each limitation of claims 1–20, and that a person of ordinary skill in the art
`
`would have had reason, with rational underpinning, to combine the
`
`references in the manner Petitioner proposes. See Pet. 18–37. Accordingly,
`
`we determine the information presented shows a reasonable likelihood that
`
`Petitioner would prevail in establishing that claims 1–20 are unpatentable
`
`under § 103 as obvious over Kirmse and Chambers.
`
`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. 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.9 RSIP describes a method for address sharing that allows a host
`
`to request that an RSIP server allocate addressing and control parameters to
`
`each host. Id. at 7. On page 10 of RSIP is a diagram, which is reproduced
`
`below:
`
`
`9 Petitioner cites to the page numbers added by Petitioner in the lowest right
`corner. We cite to the same.
`
`
`
`18
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`In this illustration, host X belongs to addressing realm A; host Y belongs to
`
`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 assignment of resources (i.e., a network address and port in
`
`addressing realm B) from the RSIP gateway. 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 5 (defining a resource as “an item that an RSIP
`
`host leases from an RSIP gateway; e.g., an address or port”). Upon
`
`assignment of the parameters, 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.
`
`This enables RSIP gateway to correctly de-multiplex and forward inbound
`
`traffic generated by Y for X. Id.
`
`2. Discussion
`
`Petitioner contends that Chambers meets most limitations, but relies
`
`on RSIP for its teaching of “NAT traversal techniques” to allocate a private
`
`IP address, along with port number (as claimed), in place of Chambers
`
`worldwide unique IP addresses, which were scarce. Pet. 39.
`
`For example, and with respect to the claim 1 limitation of “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 relies on the combined teachings of Chambers and
`
`RSIP. Pet. 43–44. In particular, Petitioner contends 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
`
`19
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`exchange session (chat session) with a participating mobile device (invitee’s
`
`phone). Id. at 43 (citing Ex. 1006 ¶ 29, Fig. 2 (step 46); Ex. 1002 ¶ 93).
`
`Petitioner relies on RSIP for its teaching of allocating a session identifier (IP
`
`address and port number) to use in a data exchange session. Id. at 43–44
`
`(citing Ex. 1013, 5, 8–10, 16–17, 22, 27–30, 36–39; Ex. 1002 ¶¶ 94–95).
`
`Petitioner provides reasons with rational underpinning, to combine
`
`Chambers and RSIP in the manner Petitioner proposes. Id. at 38–41.
`
`Patent Owner first faults the Petition as being confusing, because the
`
`Petition fails to specifically point to any of the particular structures of either
`
`Chambers or RSIP as being the required mobile device and the required
`
`server. Prelim. Resp. 13–14. We disagree. The Petition relies on the RSIP
`
`server as the claimed server. See, e.g., Pet. 44. Next, Patent Owner argues
`
`that RSIP does not disclose a mobile device (RSIP Host) sending a request
`
`to allocate a session identifier, comprising a network port number of the
`
`server of the RSIP Gateway. Prelim. Resp. 14–15. Petitioner relies on the
`
`combined teachings of Chambers and RSIP to meet the claim language of
`
`“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.” Pet. 43–44. For example, the Petition explains that
`
`Chambers discloses a server receiving a request from an initiating mobile
`
`device to allocate an IP address to use in a chat session, directing attention to
`
`Figure 2 of Chambers. Figure 2 of Chambers, shown above, shows
`
`requesting an IP address from the server (step 46), which teaches “a request .
`
`. . to allocate a session identifier.” See also Ex. 1006 ¶ 29. Moreover,
`
`Petitioner has shown that the RSIP server controls port numbers (of the
`
`server) to be allocated to RSIP hosts. See, e.g., Ex. 1013, 10, 12 (“In other
`
`20
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`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”), 30 (“[t]he ASSIGN_RESPONSE_RSAP-IP message is used by
`
`an RSIP gateway to deliver parameter assignments to an RSIP host . . .
`
`Regardless of local flow policy, a local address and port(s) MUST be
`
`assigned to the host.”). Accordingly, we are not persuaded by Patent
`
`Owner’s arguments.
`
`We have reviewed Petitioner’s showing regarding the remaining claim
`
`1 limitations. Patent Owner makes no other arguments with respect to claim
`
`1. 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. 42–50. Patent Owner’s arguments for claims 8 and 15 are the same
`
`as its arguments for claim 1, which we have addressed above. We also have
`
`reviewed Petitioner’s showing for dependent claims 2–7, 9–14, and 16–20.
`
`Id. at 50–53. Patent Owner does not contest those claims separately.
`
`Prelim. Resp. 23.
`
`Based on the current record before us, we are persuaded by
`
`Petitioner’s showing that the asserted prior art references teach or suggest
`
`each limitation of claims 1–20, and that a person of ordinary skill in the art
`
`would have had reason, with rational underpinning, to combine the
`
`references in the manner Petitioner proposes. See Pet. 37–53. Accordingly,
`
`we determine the information presented shows a reasonable likelihood that
`
`Petitioner would prevail in establishing that claims 1–20 are unpatentable
`
`under § 103 as obvious over Chambers and RSIP.
`
`21
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`E. Asserted Obviousness of Claims 1–3, 5–10, 12–17, 19, and 20
`
`over Cordenier and TURN
`
`Petitioner contends claims 1–3, 5–10, 12–17, 19, and 20 are
`
`unpatentable under 35 U.S.C. § 103(a) as obvious over Cordenier and
`
`TURN. Pet. 6, 53–75.10 In support of its showing, Petitioner relies upon the
`
`declaration of Dr. Houh. Id. (citing Ex. 1002 ¶¶ 115–158).
`
`1. Cordenier
`
`Cordenier describes a system for exchanging information between a
`
`first and a second terminal. Ex. 1007 ¶ 6. An example network including
`
`two terminals is illustrated in Figure 6 reproduced below.
`
`
`10 We understand that the challenged claims are 1–3, 5–10, 12–17, 19, and
`20 as listed at page 6 of the Petition and not claims 1–3, 5–10, and 12–20 as
`stated at page 53 of the Petition, because there is no showing for claim 18.
`
`22
`
`

`

`IPR2019-00700
`Patent 8,406,116 B2
`
`
`
`
`
`Figure 6 illustrates a telecommunications network 4 including a first
`
`terminal 1 and a second terminal 2. Id. ¶ 16. Terminals 1 and 2 (e.g.,
`
`wireless telephones) are connected to telecommunications network 4 via
`
`communication channels 8 and 9. Id. Telecommunications network 4
`
`provides access to a data network 3 via a first communication channel 10
`
`and secon