Trials@uspto.gov
`571.272.7822
`
`
` Paper No. 7
` Entered: August 28, 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-00701
`Patent 8,018,877 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
`
`
`
`
`571.272.7822
`
`
` Paper No. 7
` Entered: August 28, 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-00701
`Patent 8,018,877 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-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.”). 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 ’877 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-00700 (U.S. Patent No. 8,406,116)
`and IPR2019-00702 (U.S. Patent No. 7,969,925). Pet. 1–2.
`
`B. The ’877 Patent
`The ’877 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-00701
`Patent 8,018,877 B2
`
`
`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:
`
`
`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-00701
`Patent 8,018,877 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-00701
`Patent 8,018,877 B2
`
`
`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,
`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
`
`5
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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.
`
`D. Asserted Grounds of Unpatentability
`Petitioner asserts that claims 1–20 are unpatentable based on the
`following grounds. Pet. 5–6:
`References
`Kirmse2 and Chambers3
`Chambers and RSIP4
`Cordenier5 and TURN6
`
`Challenged Claims
`1–20
`1–20
`1–3, 5–10, 12–17,
`19, and 20
`
`Basis1
`§ 103
`§ 103
`§ 103
`
`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
`
`
`1 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.
`2 U.S. Patent No. 6,669,125 B2, issued Mar. 2, 2004 (Ex. 1005, “Kirmse”)
`3 U.S. Patent Application Pub. No. U.S. 2003/0142654 A1, published July
`31, 2003 (Ex. 1006, “Chambers”).
`4 Realm Specific IP: Protocol Specification, published by IETF no later than
`Oct. 2001, and Declaration of Sandy Ginoza (Ex. 1013, “RSIP”).
`5 European Patent Application Publication No. EP 1 385 323 A1, published
`Jan. 28, 2004 (Ex. 1007, “Cordenier”).
`6 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”).
`
`6
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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 at this time. 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
`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;7 and (4) when in evidence, objective
`
`7 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 ’877 patent.
`Pet. 10 (citing Ex. 1002 ¶ 42). At this time, Patent Owner does not propose
`an alternative assessment. Prelim. Resp. 7. To the extent necessary, and for
`purposes of this Decision, we accept the assessment offered by Petitioner as
`
`7
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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. 16–34. In support of
`its showing, Petitioner relies upon the declaration of Dr. Houh. Id. (citing
`Ex. 1002 ¶¶ 51–75).
`
`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.
`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:
`
`
`it is consistent with the disclosures in the ’877 patent and the asserted prior
`art.
`
`8
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`
`
`
`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 also provided so that one or
`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
`
`9
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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.
`
`
`Figure 4 of Kirmse shows a flowchart illustrating the process of an inviter
`client inviting an invitee into a game and having the invitee join the game.
`
`10
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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
`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
`requested 46. Id. at ¶¶ 27–29. After the IP address is requested, an
`
`11
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`invitation message, in the form of a SMS-message, is sent to the member list
`48, and once the SMS-message has been 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. 17–18 (citing Ex. 1005, 4:33–45, 7:25–8:15, Figs. 1 and 4–5).
`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.” Ex. 1001, 8:22–25.
`Petitioner contends that Kirmse describes transmitting a request to a server
`(game server) to allocate a network address and port associated with the
`server (IP address and port of game instance on game server) to use in a data
`exchange session (online game) with a participating mobile device (invitee’s
`wireless phone). Pet. 18–20 (citing Ex. 1005, 4:33–45, 5:61–65, 6:21–48,
`7:27–36, 8:1–15, 10:53–11:4, 15:35–42, Figs. 2 and 5, Fig. 4 (steps S1-S2)).
`Petitioner further contends that the request from the inviter is a request that
`the server allocate the network address and port associated with the game
`
`12
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`server so that the requester can join the session and invite others to do so.
`Id. at 19 (citing Ex. 1002 ¶ 56).
`Patent Owner argues that Kirmse does not disclose “transmitting a
`request to a server to allocate a network address and port associated with the
`server” as claimed. Prelim. Resp. 8–10. Patent Owner argues that there is
`nothing in Kirmse that describes a mobile device requesting to allocate a
`network address and port associated with the server, because the server of
`Kirmse serves active games where the session identifier, such as port
`number, is already known to the game client. Id. at 9 (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. 18–20. 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 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 “receiving the network address and port from
`the server.” Ex. 1001, 8:26. Petitioner contends, for example, that Kirmse’s
`
`13
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`description of step S4 (Fig. 4) meets 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. 21–22
`(citing Ex. 1005, 7:27–36, Fig. 4, step S4).
`Claim 1 also recites “using a page-mode messaging service to assist in
`communicating the network address and port number to the participating
`mobile device, wherein the page-mode messaging service utilizes a unique
`identifier to locate the participating mobile device.” Ex. 1001, 8:27–31.
`Petitioner contends that Kirmse describes that 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. 23 (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 ¶
`60). 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 25 (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 25–26 (citing Ex. 1006 ¶¶ 4, 30, 31, 34–37, Fig. 1; Ex. 1002 ¶ 62).
`Petitioner provides reasons, with rational underpinning, to combine Kirmse
`and Chambers. Id. at 26–28 (citing Ex. 1002 ¶¶ 63–67).
`Claim 1 recites “participating in the data exchange session with the
`participating mobile device through the server, wherein the participating
`
`14
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`mobile device has established a connection with the server using the network
`address and port.” Ex. 1001, 8:32–35. Petitioner contends that Kirmse
`describes participating in the data exchange session (online game) with the
`participating mobile device (invitee wireless phone) through the server
`(game server), wherein the participating mobile device has established a
`connection with the server using the network address and port (steps S11–
`S12). Pet. 28–29 (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, 9:14–55, 11:44–60, 15:35–44, 17:35–52, Figs. 3, 4, 7, 10, 11E;
`Ex. 1002 ¶¶ 68–69).
`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. 17–30. 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.
`8–10. We also have reviewed Petitioner’s showing for dependent claims 2–
`7, 9–14, and 16–20. Id. at 31–34. Patent Owner does not contest those
`claims separately. Prelim. Resp. 21.
`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. 17–34. 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.
`
`15
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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. 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.8 RSIP is 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:
`
`
`
`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
`
`
`8 Petitioner cites to the page numbers added by Petitioner in the lowest right
`corner. We cite to the same.
`
`16
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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. 36.
`For example, and with respect to the claim 1 limitation of
`“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 relies on the combined teachings of
`Chambers and RSIP. Pet. 40–41. In particular, Petitioner contends 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. Id. at 40 (citing Ex. 1006 ¶ 29, Fig. 2 (step 46);
`Ex. 1002 ¶ 87). Petitioner relies on RSIP for its teaching of an RSIP host
`transmitting a request (REGISTER_REQUEST (with the no remote flow
`policy to support multi-way conferencing) followed by an
`ASSIGN_REQUEST_RSIP-IP or a LISTEN_REQUEST)) to a server (RSIP
`Server) to allocate a network address and port associated with the server
`(public IP address and port of RSIP Sever) to use in a data exchange session
`with participating devices. Id. at 40–41 (citing Ex. 1013, 5, 8–10, 16–17, 22,
`27–30, 36–39, 49–51; Ex. 1002 ¶ 88). Petitioner provides reasons with
`
`17
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`rational underpinning, to combine Chambers and RSIP in the manner
`Petitioner proposes. Id. at 35–38.
`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. 10–12. We disagree. The Petition relies on the RSIP
`server as the claimed server. See, e.g., Pet. 41. Next, Patent Owner argues
`that RSIP does not disclose transmitting a request to a server to allocate a
`network address and port associated with the server. Prelim. Resp. 12–13.
`Petitioner relies on the combined teachings of Chambers and RSIP to meet
`the claim language of “transmitting a request to a server to allocate a
`network address and port associated with the server.” Pet. 40–41. For
`example, the Petition explains that Chambers describes transmitting a
`request to a server (stationary address server) to allocate an IP address to use
`in a data exchange session (chat session), directing attention to Figure 2 of
`Chambers. Id. Figure 2 of Chambers, shown above, shows allocating an IP
`address from the server (step 46), which teaches “transmitting 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
`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.
`
`18
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`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. 39–45. 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 45–48. Patent Owner does not contest those claims separately.
`Prelim. Resp. 21.
`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. 39–48. 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.
`
`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
`
`19
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`TURN. Pet. 48–68.9 In support of its showing, Petitioner relies upon the
`declaration of Dr. Houh. Id. (citing Ex. 1002 ¶¶ 106–140).
`
`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:
`
`
`9 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 48 of the Petition, because there is no showing for claim 18.
`
`20
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`
`
`
`Figure 6 illustrates a telecommunications network 4 including a first 1 and a
`second terminal 2. Id. ¶ 16. The terminals 1 and 2 are connected to the
`telecommunications network 4 via communication channels 8 and 9. Id.
`The telecommunications network 4 provides access to a data network 3 via a
`first communication channel 10 and second communication channel 11 for
`the first terminal 1 and second terminal 2 respectively. Id. Terminals 1 and
`2 respectively establish connections 10 and 11 to data network 3 by logging
`
`21
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`onto a server 15 that communicates respective network addresses to
`terminals 1 and 2. Id. Figure 6 further illustrates a signaling network 5,
`where terminals 1 and 2 are also connected to the signaling network 5 via
`communication channels 12 and 13. Id. Cordenier describes that the first
`terminal 1 communicates with the data network 3 via the telecom network 4
`and has a first message 6 containing a first network address that is sent to the
`second terminal 2 using the signaling network 5. Id. Cordenier further
`describes that the first message 6 is an SMS message, where the first
`network address is coded as a hidden code within the first message 6. Id. In
`response, the second terminal 2 sends one of second messages 7a, 7b, or 7c
`to the first terminal 1. Id. ¶¶ 16, 17.
`
`2. TURN
`TURN (Traversal Using Relay NAT) is a technical specification that
`describes how a client behind a symmetric NAT (Network Address
`Translator) can send and receive data from another host on the internet. Ex.
`1009, 4–5.10 TURN is a client-server protocol containing a single request
`message—Allocate—that asks for a public IP address and port. Id. at 8.
`Figure 1, reproduced below, illustrates a TURN configuration:
`
`
`10 Petitioner cites to the page numbers added by Petitioner in the lowest right
`corner. We cite to the same.
`
`22
`
`
`
`IPR2019-00701
`Patent 8,018,877 B2
`
`
`
`
`As illustrated in Figure 1, TURN client is connected to Private Network 1;
`Private Network 1 connects to Private Network 2 through NAT 1; Private
`Network 2 connects to the Public Internet through NAT 2; and the Public
`Internet is a TURN Server. Id. at 4. Specifically, there are three types of IP
`addresses and ports that can be requested: (1) source IP address and port
`(SA:SP); (2) public IP address and port (PA:PP); and remote IP address and
`port (RA:RP). Id. at 5. When a TURN client discovers the address of a
`TURN server, and sends an Allocate request to the TURN server, the TURN
`server stores this request as SA:SP. Id. In response to the Allocate request,
`and after the authentication process, the TURN server returns a PA:PP to the
`TURN client—TURN response. Id. Further, any incoming connections to
`the TURN server are stored as RA:RP. Id. Thus, the TURN server
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
