Trials@uspto.gov
`571-272-7822
`
`
`
`
`Paper No. 16
`Date: June 5, 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)
` IPR2019-00701 (Patent 8,018,877 B2)1
`____________
`
`Record of Oral Hearing
`Held: May 21, 2020
`____________
`
`
`
`
`Before SALLY C. MEDLEY, JEFFREY S. SMITH and
`JOHN F. HORVATH, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`BRIAN K. ERICKSON, ESQ.
`JEFF R. COLE, ESQ.
`DLA Piper, LLP (US)
`401 Congress Avenue, Suite 2500
`Austin, Texas 78701
`
`
`
`JAMES M. HEINTZ, ESQ.
`DLA Piper, LLP (US)
`One Fountain Square
`11911 Freedom Drive, Suite 300
`Reston, Virginia 20190
`
`MARC M. BREVERMAN, ESQ.
`Apple, Inc.
`1 Apple Park Way
`Stop 169-2Nyj
`Cupertino, California 95014
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`BRETT A. MANGRUM, ESQ.
`Etheridge Law Group, PLLC
`2600 East Southlake Boulevard, Suite 120-324
`Southlake, Texas 76092
`
`
`
`
`The above-entitled matter came on for hearing on Thursday, May 21,
`
`2020, commencing at 1:00 p.m., EDT, by video.
`
`
`
`2
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE MEDLEY: Good afternoon. This is the combined hearing
`
`for IPR 2019-00700 involving U.S. Patent No. 8,406,116 and IPR 2019-
`00701 involving U.S. Patent No. 8,018,877.
`
`At this time, we’d like the parties to please introduce themselves for
`the record beginning with the Petitioner.
`
`MR. ERICKSON: Thank you. This is Brian Erickson with DLA
`Piper on behalf of Petitioner, Apple. May I have permission of the Board to
`address the Board while seated?
`
`JUDGE MEDLEY: Yes, that’s fine.
`
`MR. ERICKSON: Thank you. With me by video conference is Jim
`Heintz from DLA Piper and joining us via the public telephone access is
`Marc Breverman, in-house counsel at Apple, and Jeff Cole also at DLA
`Piper.
`
`JUDGE MEDLEY: And you will be presenting arguments?
`
`MR. ERICKSON: Yes, I will. Thank you.
`
`JUDGE MEDLEY: Okay. Great.
`
`And for Patent Owner, who do we have?
`
`MR. MANGRUM: Good afternoon, Your Honors. This is Brett
`Mangrum with the Etheridge Law Group representing the Patent Owner,
`Uniloc and I will be --
`
`JUDGE MEDLEY: Okay.
`
`MR. MANGRUM: -- presenting on behalf of Patent Owner today
`and there will be no one else joining on behalf of Patent Owner.
`
`JUDGE MEDLEY: Okay. Thank you everyone.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`3
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`So as you know from the order that we sent out, each party will have
`
`45 minutes total time to present arguments. Petitioner, you will proceed first
`and may reserve some of your argument time to respond to arguments
`presented by Patent Owner. Thereafter, Patent Owner will respond to
`Petitioner’s presentation and may reserve argument time for surrebuttal.
`
`Petitioner, do you -- counsel for Petitioner, do you wish to reserve
`some of your time to respond?
`
`MR. ERICKSON: Yes, Your Honor. I would like to reserve 20
`minutes.
`
`JUDGE MEDLEY: Okay. And I might not, you know, keep you up
`to date, so -- if I’m engrossed in what you’re saying, so just keep track of
`your time. Okay?
`
`MR. ERICKSON: Understood. Thank you, Your Honor.
`
`JUDGE MEDLEY: Okay. Thank you. You may begin when you’re
`ready.
`
`MR. ERICKSON: May it please the Board. I intend to proceed as
`outlined on Slide 2 of Petitioner’s demonstratives. Specifically, I’ll provide
`a very brief overview of the patents and then I’ll step through each of the
`three contested issues in the IPR, one for each of the three asserted grounds.
`
`Turning to Slide 3, the challenged patents are part of a very large
`patent family that’s broken into a couple of sub-groups. The first sub-group
`is referred to by the challenged patent as the “P2P application” and the
`challenged patents are all directed to new matter, specifically matter that was
`added to overcome what’s called NAT traversal techniques. But as
`established in the challenged grounds, these NAT traversal techniques were
`already well-known and, in fact, had been standardized long before the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`4
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`challenged patents had been filed.
`
`Turning to Slide 4, this presents Figure 2 of the challenged patents
`and the highlighting here is to illustrate that the ‘116 Patent, the claims are
`directed primarily to functions or actions that are occurring at the server and
`that is in the left column here shown highlighted in Figure 2.
`
`
`Turning to Slide 5, we have the ‘877 Patent and this is again Figure 2
`of the challenged patents and you see the highlighting shows that the claims
`are directed primarily to actions or functions that are occurring on the
`initiating mobile device.
`
`Turning to the asserted grounds on Slide 6, all claims are obvious over
`the combination of Kirmse and Chambers. Turning to Slide 7, we’ve
`produced Claim 1 of both challenged patents on Slide 7 and highlighted the
`language in dispute. I’ve quoted a sub portion of the first limitation that’s in
`dispute. You can see that I’ve left off some of the language that is not
`disputed in the claims. So the relevant dispute is focused on the language,
`the request to allocate, “to use in a data exchange session with a
`participating mobile device.”
`
`So that’s a portion of the first claim limitation. I have not included
`the language that is uncontested such as the fact that the communication is
`received at a server, it’s sent from a mobile device, what’s being allocated is
`an address and port of the server. There’s no dispute there. The only
`dispute with respect to Ground 1 is whether that communication is a request
`to allocate. Again, there’s no dispute about any other limitation of any other
`challenged claim. There’s no dispute that the combination would have been
`obvious to a person of ordinary skill.
`
`Turning to Slide 8, Kirmse clearly discloses a request, for example a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`5
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`communication from an inviter to a game server, to allocate, for example
`distribute an IP address and port of the server, to use in a data exchange
`session, for example to play a game, or a white board session, or a
`conference like we’re having here, with a participating mobile device, what
`Kirmse calls an invitee.
`
`Now, no party has proposed construction of the term “allocate.”
`There’s no dispute that it should be entitled to its plain and ordinary
`meaning. In the reply, in reply to Patent Owner’s bringing up this dispute,
`we have provided an example of one definition of “allocate” from a
`dictionary, that is “to apportion for a specific purpose or two particular
`persons or things; distribute.” There’s no question that Kirmse clearly
`discloses “allocate” under its ordinary meaning.
`
`Turning to Slide 9 --
`
`JUDGE MEDLEY: So I have a question for you --
`
`MR. ERICKSON: Yes?
`
`JUDGE MEDLEY: In your petition, it seems to me that you also
`equate “allocate” with “distribute.” Particularly, I’m looking at page 20 --
`
`MR. ERICKSON: Yes, Your Honor. This is --
`
`JUDGE MEDLEY: -- of the petition.
`
`MR. ERICKSON: Yes, Your Honor. I’m familiar with the passage
`you’re referring to. It is true that we used the word “distribute,” but
`“allocate” is not used in isolation there. We’re not proposing -- while the
`dictionary definition does imply that they’re synonymous, we’re not
`implying that “allocate” would exclusively mean or should be construed to
`mean “distribute.”
`
`In the overall context of the claim, it’s a request to allocate for a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`6
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`specific purpose and so it’s distributed to a requestor for that purpose and so
`it’s very close to being synonymous with “distribute,” but “allocate” carries
`probably a little additional meaning to “distribute” and that is provided for
`that purpose. The purposes set forth in the claims is to use in a data
`exchange session with a participating mobile device and so we have a
`request coming in from the inviter to the server, the server responds to that
`request by distributing or providing the requested connection details for the
`claimed purpose which is to use in a data exchange session with a
`participating mobile device.
`
`So does --
`
`JUDGE MEDLEY: Okay. I was just --
`
`MR. ERICKSON: -- Your Honor --
`
`JUDGE MEDLEY: I was just getting to the point I think in their -- I
`believe in their surreply they said that, you know, your definition was new,
`that they couldn’t have seen that coming, et cetera, but I see here that you
`sort of do equate “to allocate” means to distribute all along. That’s the way I
`understand it.
`
`MR. ERICKSON: That’s correct, Your Honor. In the context of
`Kirmse’s disclosures, the request and distribution in response to that request
`of the required connection details, we do believe satisfies the ordinary
`meaning of “allocate”. There is kind of a one-to-one correspondence there
`as you point out in our petition that it’s clear that we were using “distribute”
`in place of “allocate” there as we showed how Kirmse disclosed “allocate”
`under its ordinary meaning.
`
`JUDGE MEDLEY: So in Patent Owner’s, arguments, what is your
`understanding of their construction “to allocate”? Do you think it means to
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`7
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`generate something?
`
`MR. ERICKSON: Yes. Yes, Your Honor. And if we could move
`forward to Slide 12, we do think Patent Owner got off on the wrong track by
`looking at an unclaimed embodiment, specifically the embodiment of Figure
`3 where there is a different, separate and unique token which they call a
`“session ID” in Figure 3.
`
`There are preexisting ports and addresses, but what’s used as a session
`ID in Figure 3 is a separate and unique generated token and that’s generated
`after and in response to the request and that’s passed in addition to the
`connection details. The token is passed to the inviting device so it can
`distribute that token. And in Figure 3, all devices join at the same address
`and port and the way the connection is made by the server is by that unique
`token that was generated.
`
`So we think Patent Owner relied on those passages in its Patent
`Owner response and I believe that the arguments it’s making are all
`contingent on an implied construction of “generate” in place of “allocate.”
`
`If you turn back a slide to Slide 11, you’ll see where Patent Owner
`makes the argument in the Patent Owner’s response and this is almost the
`entirety of its argument on the substance. It states that in Kirmse the
`connection details may be existing prior to the request and then it contrasts
`with the word “allocate.” So this is either an ipsis verbis test where Patent
`Owner is arguing that because Kirmse doesn’t use the word “allocate” it
`doesn’t disclose allocate and we know that’s not sufficient, or Patent Owner
`here is implying that it cannot pre-exist -- it cannot exist prior to the request.
`
`So yes, I believe Patent Owner’s argument is implicitly that “allocate”
`should be construed to mean “generate” and that’s incorrect. We believe
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`8
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`that it’s not required by the ordinary meaning of “allocate.” It’s only
`addressed in an embodiment. Even if it were a claimed embodiment, it
`would be improper to convert “allocate” to “generate” or require some lack
`of existence prior to the request. And so in answer to Your Honor’s
`question, yes. We believe Patent Owner is trying to narrow the claim saying
`it cannot exist prior to the request and must be generated.
`
`JUDGE MEDLEY: Okay. Thank you. So just to follow-up then, if
`that is the construction that they’re proposing and, you know, we find that
`persuasive -- I’m not saying that one way or another, but let’s just explore --
`does Kirmse teach that then, to generate with starting a game?
`
`MR. ERICKSON: Yes, Your Honor. That is our position and we
`submit that is clearly disclosed in Kirmse. It’s certainly obvious to a person
`of ordinary skill as supported by the declaration of Dr. Houh that if the game
`hadn’t been started yet, those parameters would not have been generated.
`
`Although I must say, “generated” in the context of addresses and
`ports, I don’t think any expert would believe that an address and port would
`ever be generated at a point in time. These are typically things that when the
`computer boots up they have, you know, 16,000 ports and they are -- they
`compute. The server itself would have an IP address.
`
`So these are not things that I think would be properly ever
`characterized as generated and that’s why the specification in the patent
`never refers to generating the address and port. So to the extent the Board
`found that persuasive, we believe that that construction would exclude all
`disclosed embodiments.
`
`JUDGE MEDLEY: Okay. Thank you.
`
`JUDGE SMITH: I have a question about that. So the claims from the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`9
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`‘116 Patent talk about a session identifier so that would be possible to be
`generated, would it not?
`
`MR. ERICKSON: So the claims -- if we could turn back to Slide 7
`where we have Claim 1, the claims do recite a session identifier as Your
`Honor correctly notes. Just below the highlighted portion on Slide 7 you
`have a “wherein” clause which states, “Wherein the session identifier
`comprises a network port number of the server.”
`
`And so if the session ID comprises a network port, I think we’ve run
`into that situation where the network port number is never generated. At
`least that would be a, I believe, an awkward or inappropriate way to describe
`what’s happening with the network port. Those things just exist by nature of
`the hardware that accepts so many different, I think 16,000, you know,
`addresses and ports.
`
`JUDGE SMITH: And then for the -- starting the game, did you make
`that argument in the petition or was that only in the reply?
`
`MR. ERICKSON: Your Honor, we did discuss starting a game in the
`petition. We did not go so far as to expressly say at the start of a game
`something would be generated and we don’t think that’s a viable
`construction in light of the intrinsic record, but that was not anticipated until
`the Patent Owner’s response where they have I think implicitly argued that
`these things cannot exist prior to the request.
`
`JUDGE SMITH: And I have just one last question about this. Does
`the patent itself have an embodiment where these session identifiers are
`distributed rather than generated as part of the scope of allocation?
`
`MR. ERICKSON: Yes, Your Honor. The -- Figure 2 which is the
`claimed embodiment here, this is a situation where the session ID as shown
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`10
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`by that “wherein” clause is restricted to include the network port number of
`the server. That restriction is to Figure 2. It excludes Figure 3 where the
`session ID is generated because it’s a unique token generated after the
`request. So you’re talking about preexisting port numbers that exist on a
`server and that are provided to the mobile device in response to its request.
`
`JUDGE MEDLEY: Could you tell us which step in Figure 2 you’re
`talking about and where it distributes rather than generates, if you will?
`
`MR. ERICKSON: So if we turn back to Slide 5, so we’re on Figure 2,
`and we see step 230. So prior to distributing it to the mobile device which is
`the arrow going from box 230 to 235, that would be the allocation to the
`mobile device. The figure also includes this part of step 230 opening a
`specific port number. Opening a port is obviously a claim construction issue
`in the ‘702 IPR which will be addressed at the next hearing, but that port
`already exists on the server.
`
`It’s never generated. It may be opened and assigned to a process, for
`example a game that is being started in response to a request, but the claim
`term here at issue is “allocate” and not just allocate to the game. It’s not
`saying allocate to the game. It’s not saying allocate to a process. It’s saying
`allocate “to use in a data exchange” with the other device and that’s what
`Kirmse is disclosing.
`
`If we go back to Slide 9 -- or, in fact, let’s go back to Slide 10. Slide
`10 addresses Figure 1 in Kirmse in the accompanying text where Figure 1
`discloses there can be multiple active games. So let’s assume, and you
`already -- all of the games are already running. Let’s assume the games
`have ports and addresses allocated to them. What’s relevant is when the
`inviter says, “I need connection details” not when the game needs
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`11
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`connection details.
`
`And so the request comes in from the inviter and the server says
`which of these connection details should I provide to that inviter and it
`allocates it to that device for that purpose, specifically as disclosed in
`Kirmse. The inviter will then send that to the invitee and the inviter will be
`able to play the game with the invitee. That’s the relevant claim language
`here. It’s “to use in a data exchange session with a participating mobile
`device”.
`
`So we think Patent Owner is shifting the focus to say well, if we’re in
`the situation where we’re joining a game, then maybe that game has already
`been allocated connection details is looking at the wrong allocation. It’s
`when its allocated to the inviter for the claim purpose of “use in a data
`exchange with a participating mobile device” and that’s the step that’s
`relevant in Kirmse.
`
`Let’s see. Moving forward to Slide 14, I think it is an extension of
`this issue. Patent Owner tries to distinguish Kirmse as cited here on Slide
`14. It says well, Kirmse teaches that multiple game clients, including the
`inviter and invitees may use the port reference.
`
`So it’s not clear exactly how Patent Owner is trying to distinguish
`Kirmse here, but it’s not legitimate to distinguish it on that basis because, in
`fact, that’s required by dependent Claim 4 and the rest of the specification
`including the portion cited in the reply, Column 5, that says that that’s
`exactly what you’re going to do. The inviter is going to distribute this to
`multiple different inviters -- invitees, excuse me -- so that multiple different
`devices can join in a multi-way conference or a game with the inviter.
`
`So I think this is an extension of Patent Owner’s erroneous approach
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`12
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`to this limitation that says these things must not exist until there’s the
`request by the inviter. These things can already be allocated for multiple
`purposes. They don’t have to be generated in response to the request. And
`again, you can allocate to one inviter and then that inviter can pass it around
`to multiple other players.
`
`So, by extension, there could be other players already in that game. It
`could be ongoing. You could have five players in there, a new inviter comes
`up and says, “I would like to play the game.” The server would allocate to
`that inviter the credentials that may already exist so that that inviter can then
`invite other invitees and they could have 10 or 20 different players playing
`this game.
`
`Finally, on Slide 15, Patent Owner argues that Kirmse also discloses a
`fallback URL could be used. That’s certainly true. As shown on Slide 15,
`certain invitees may not have a local game client so they need to play it
`through a web browser. In that case, they can use the fallback URL. That
`has nothing to do with the disclosure in Kirmse that’s relied on as part of the
`petition where they do have game clients installed and do use the address
`and port of the server.
`
`Finally, Slide 16 of Patent Owner’s argument that the game client may
`already know the credentials or connection details. That’s a possibility. For
`example, the invitee will have received the credentials through SMS and it
`will not need to obtain them from the server, but as we have shown Kirmse
`discloses that some inviters need the connection details from the server and
`they have to obtain them through the process disclosed and cited again here
`for the second time on Slide 16.
`
`If there are any other questions about Ground 1, I’ll move to Ground
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`13
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`2.
`JUDGE MEDLEY: No, not from me. Thanks.
`
`MR. ERICKSON: Thank you, Your Honor.
`
`With respect to Ground 2, all challenged claims are obvious over the
`
`combination of Chambers and RSIP. Moving to Slide 18, there’s a different
`sub-portion here of the first claim that’s at issue. The only dispute is
`whether the address and port allocated by the RSIP server is of the server or
`associated with the server as claimed in the respective patents.
`
`There’s no dispute about the other limitations in any of the challenged
`claims. There’s no dispute it would have been obvious to combine
`Chambers and RSIP to accomplish NAT traversal and in light of the lack of
`any other disputes including the later limitations in the claim, for example,
`as we see here in Claim 1 of the ‘116 patent on the left, you have
`“establishing” -- this is the second to last limitation -- “establishing, at the
`server, connections between the mobile device and participating mobile
`device based on the session identifier against the session identifier”
`including the number of the server as we just discussed.
`
`There’s no dispute that the connection is made through the server at
`that port number. In light of the lack of disputes about the whole reason for
`the combination and the later limitations that require the connection be
`established there and facilitated through the server, it is clear that there is no
`merit in Patent Owner’s argument that the RSIP server is somehow
`allocating something of the RSIP Host(s).
`
`So turning to Slide 19, there’s no dispute that the RSIP server
`allocates an address and port. The sole dispute is whether that is of the RSIP
`server or of the Host.
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`14
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`Turning to Slide 20, the Board correctly understands the architecture
`
`of RSIP. In light of the time constraints, I will skip through most of these
`slides but just from an overview perspective, the RSIP Host is in the private
`address realm, address space A. The RSIP Gateway is at the boundary of
`the two address spaces and the remote Host is over on the right. Y is in the
`address space, in the public address space, address space B. The private
`realm is defined by RSIP to be an address staring with either 10, 172 or 192.
`Again, if the Host already had a public address, we wouldn’t even be talking
`about the combination with RSIP. If the Host already had a public address
`and port, you wouldn’t be using RSIP. The whole reason it’s undisputed for
`the proposed combination is that the RSIP Host in the combination of
`Chambers is a mobile phone in a private address space and it cannot send its
`private address by SMS to the recipient because that will be meaningless to
`the recipient and so it needs to obtain a public address and port from the
`RSIP Gateway.
`
`Moving forward to Slide 22, the RSIP Gateway here is on the bridge
`of the two addresses spaces. It’s denoted as N in the figure. As you can see
`in the highlighted text, that, “N may have a pool of address in address space
`B which it can assign to or lend to X and other Host(s) in address space A.
`These addresses are not shown above, but they can be noted as Nb1,” 2 “and
`so on.” Those are the addresses and ports they’re allocating. That’s the
`entire reason for RSIP’s existence, is that the RSIP Host is in a private
`address space and needs to have a public address and port.
`
`Moving forward to Slide 24, this points out the fact that Patent Owner
`does not dispute that for the later limitations that outbound communications
`will go from the RSIP Host to the RSIP Gateway. The RSIP Gateway will
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`15
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`then swap out the header or strip the header that’s -- the original header and
`send it out to the remote Host.
`
`And then turning to Slide 25, it’s undisputed that the incoming
`transmissions from the remote Host will go to the public address on the
`RSIP Gateway where the RSIP server is running and then be routed and sent
`over to private space to the RSIP Host.
`
`Turning to Slide 26, so that’s the assigned request. The RSIP Host
`requests resources. You can see as highlighted on Slide 26, resources are
`defined as “the things that are -- that the RSIP host leases from the RSIP
`Gateway, e.g. an address and port.” So those are the addresses and port of
`the RSIP server that are being allocated to the Host for purposes of NAT
`traversal.
`
` One last point on Slide 27. This is the concrete example in RSIP
`that’s relied on in the petition and the reply and it is never addressed by
`Patent Owner. You can see the assigned request. The address local is
`specified as 0. As explained by RSIP, that means the RSIP Host doesn’t
`care what public address is assigned, it just wants a public address.
`
`In response, the RSIP server assigns -- you see address local
`beginning with 149. Remember, as we discussed earlier, that the private
`addresses of the RSIP Host which start with either 10, 172 or 192, here
`you’re being -- you’re seeing assigned a public address and ports of the
`RSIP Gateway.
`
`We think that Patent Owner’s contention that those could somehow be
`the address and port of the Host which would defeat the whole purpose of
`RSIP and turn everything on its head, the RSIP Host would never go to the
`RSIP server if it already had a public address and port.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`16
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`Moving to Ground 3, very briefly. I think I’m already over time.
`
`Patent Owner’s sole dispute with respect to Cordenier and TURN is that
`Cordenier -- that TURN introduces a relay server. There’s no incompatibility
`between TURN and Cordenier. Going all the way forward to Slide 34, this
`illustrates on the invention in Cordenier. You have the SMS request going
`over as shown at the top and there are six that carries the address to the
`inviter for the embodiments in Cordenier where they will end up needing to
`use a NAT. That would, of course, be meaningless.
`
`And so in order to accomplish that NAT traversal, they would -- a
`person of ordinary skill would use TURN. Again, there’s no dispute on the
`primary aspects of the showing of invalidity established as obviousness
`established in the petition. There’s just this one issue that the Patent Owner
`says it would be inconsistent to use a relay server in light of Cordenier.
`
`But Cordenier states explicitly, as shown on Slide 34, that “it may…
`be necessary to route IP-traffic from the first and second terminal, 1, 2 to a
`network address translator connected to the data network”. So Cordenier
`expressly contemplates an intermediating server, specifically a NAT. So
`there is no teaching in Cordenier that the invention is only applicable
`without a relay server.
`
`Cordenier was teaching the lack of an IP exchange server and
`substitutes that with the SMS invitation so that the parties do not have to log
`into something like AOL or Yahoo or something where they say, “I am here.
`I am online. Here is my user name. Here is my IP address,” and they log
`into that common server to be able to connect with each other.
`
`Cordenier is about substituting that with an SMS invitation, but with
`respect to these communications through the internet, that can, of course, use
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`17
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`a NAT as expressly disclosed by Cordenier. Cordenier also discloses using
`the SMS in the figure. The address, the IP-address server, 15, so that the
`terminals can obtain IP-addresses to be able to communicate over the
`internet in the first place. So they’re completely consistent with Cordenier.
`
`Moving forward to Slide 31, in both Cordenier and TURN, the mobile
`devices obtain IP addresses from address servers. In the combination, you
`would still use an SMS invitation instead of a common IP exchange server
`and in the combination you would still route IP-traffic through a NAT. And
`specifically, that’s what the N in TURN stands for is NAT. It’s a TURN,
`traversal using relay NAT. That’s on page 1 of the specification. On page
`2, they elaborate further on why TURN is a NAT. This is cited at the
`petition at page 45 -- sorry, 54 and 49 respectively.
`
`Subject to any questions of the Board, I’ll reserve the rest of my time,
`if any, for rebuttal.
`
`JUDGE MEDLEY: Okay. Yes, I have you down as having
`approximately 17 minutes left.
`
`MR. ERICKSON: Thank you, Your Honor.
`
`JUDGE MEDLEY: Okay. And just one second.
`
`Okay. Mr. Mangrum, would you like to reserve time?
`
`MR. MANGRUM: Sorry, I was on mute. Let me get off mute. Yes,
`I would like to reserve 10 minutes. I understand that would give me 35
`minutes in-chief.
`
`JUDGE MEDLEY: Okay. That sounds good. And again, I, you
`know, won’t probably remind you, so just keep track of your time and you
`can proceed whenever -- when you’re ready.
`
`MR. MANGRUM: Okay. I do want to draw -- excuse me -- Your
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`18
`
`

`

`IPR2019-00700 (Patent 8,406,116 B2)
`IPR2019-00701 (Patent 8,018,877 B2)
`
`Honor’s attention to a few differences that I think were not emphasized in
`the opposing counsel’s remarks today between the two different patents.
`
`It is true when you compare Claim 1 of the ‘116 Patent and Claim 1 of
`the ‘877 Patent that they’re written from different perspectives. The ‘116
`Patent is written from the perspective of a server and so the receiving and
`transmitting acts for Claim 1 are written from a perspective of a server
`performance and then that may be compared with Claim 1 of the ‘877 Patent
`where the preamble is somewhat similar. It provides the context of initiating
`a data exchange among mobile devices, but then what you get to are
`transmitting and receiving, participating steps that are decided from the
`context initiating mobile device. I think that’s undisputed.
`
`But one thing that’s important to recognize also