`
`
`U.S. PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`RIOT GAMES, INC. And VALVE CORP.,
`Petitioner
`
`v.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`__________
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`__________
`
`Record of Oral Hearing
`Held: February 13th, 2019
`__________
`
`Before THU A. DANG, KARL D. EASTHOM, NEIL T. POWELL,
`Administrative Patent Judges.
`
`
`
`
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER RIOT GAMES:
`SCOTT M. BORDER, ESQ.
`SAMUEL A. DILLON, ESQ.
`JOSEPH A. MICALLEF, ESQ.
`of: Sidley Austin, LLP
`1501 K Street, NW
`Washington, D.C. 20005
`(202) 736 8818 (Border)
`(202) 736 8298 (Dillon)
`sborder@sidley.com
`samuel.dillon@sidley
`
`
`ON BEHALF OF THE PETITIONER VALVE CORP.:
`SHARON A. ISRAEL, ESQ.
`of: Shook, Hardy & Bacon, LLP
`600 Travis Street
`Suite 3400
`Houston, Texas 77002
`(713) 546 5689
`sisrael@shb.com
`
`
`ON BEHALF OF THE PATENT OWNER:
`GREGORY M. HOWISON, ESQ.
`KEITH D. HARDEN, ESQ.
`BRIAN D. WALKER, ESQ.
`Of: Munck Wilson Mandala, LLP
`600 Banner Place Tower
`12770 Coit Road
`Dallas, Texas 75251
`(972) 628 3616
`ghowison@munckwilson.com
`
`
`The above-entitled matter came on for hearing on Wednesday,
`
`February 13, 2019, commencing at 10:05 a.m. at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`2
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`
`P-R-O-C-E-E-D-I-N-G-S
`
`10:05 a.m.
`
`JUDGE EASTHOM: Okay, welcome, everybody.
`Riot Games, Inc. and Valve Corp. v. Paltalk Holdings, Inc. We
`have four cases here and four other cases are joined to those: Cases IPR
`2018-00129 with IPR 2018-0242 joined to that, and IPR 2018-00130 with
`IPR 2018-01241 joined to that. Those cases collectively challenge all the
`claims in Patent 5,822,523. Then we have IPR 2018-00131 with IPR 2018-
`01238 joined to that, and IPR 2018-00132 with IPR 2018-1243 joined to
`that. And those cases collectively challenge the claims in Patent
`6,226,686.Petitioner -- the parties have asked for an hour for the four cases
`collectively. And Petitioner has the burden of proof. So, Petitioner will
`proceed first and then, if you want to reserve rebuttal time, let me know.
`Patent Owner will go after Petitioner's first showing and then, if you
`want to reserve rebuttal time, you can reserve that also.
`Give me a second to see if I can figure this clock out again.
`Patent Owner -- Petitioner, will you want to reserve time?
`MR. HOWISON: Your Honor, we'd like to reserve 20 minutes for
`rebuttal.
`JUDGE EASTHOM: Okay. Okay, why don't we have the parties
`introduce themselves for the record?
`
`
`
`3
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`MR. MICALLEF: Joe Micallef for Petitioner, Riot Games, and
`Sidley Austin. And these are my partners, Scott Border, who will be
`making the argument for Petitioners; my colleague, Sam Dillon; my partner
`John McBride. And also with us is counsel for Valve Corporation, Sharon
`Israel.
`
`JUDGE EASTHOM: Okay.
`MR. BORDER: Good morning, Your Honors.
`Your Honor, as you mentioned, there are four proceedings that we
`are discussing today, but there are only a handful of contested issues. My
`presentation intends to focus on those contested issues.
`Go to slide 2, please?
`And I'd like to start first with a brief overview of the contested
`patents. I then want to go into our main combination of prior art which the
`Aldred and RFC 1692 reference.
`And, next, I plan on handling the independent claim disputes and
`there are two, and they are essentially the same across all four proceedings.
`The first dispute is whether Petitioner displayed an express
`motivation combined RFC 1692 with Aldred. Patent Owner has challenged
`our showing, but as I'll discuss, we think it's based on an unsupported
`hypothetical and is unsupported by the record.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`4
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`The second dispute is over claim construction. Patent Owner has
`litigated these patents for over a decade and only until this proceeding did
`they argue this transport layer everywhere.
`My colleague, Sam Dillon, will address the dependent claim disputes
`when I'm done discussing the independent claims case.
`Can we go to slide 4, please?
`Two patents involved, each with the same priority date, February 1st,
`1996. All of our prior art is 102B prior art and Patent Owner no longer
`contests the prior art status of those references.
`Slide 5, please?
`This is a depiction of Patent Owner's invention that they submitted in
`a ex parte re-exam. They described it as essential server that communicates
`with multiple clients.
`The central server has group messaging capabilities. You can create
`and join groups. Clients can send messages to servers and the server then
`distributes those messages to the clients.
`There's no dispute that Aldred discloses each of those features. It
`also has the feature of aggregating message payloads prior to distributing to
`each of the clients. That is central to this queue here. We show that RFC
`1692 shows that aggregated by maintenance.
`Slide 8, please?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`5
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`Independent Claim 1 is representative of -- for the 523 and 686, are
`representative of all the independent claims in this proceeding.
`I highlighted the aggregating step that is one of the focuses of the
`contested issues.
`Also, underlined, the terms aggregated messaging and aggregated
`payload. Those are the two constructions that are in dispute between the
`parties.
`Slide 9, please?
`Before we get into the disputes related independent claims, I wanted
`to talk briefly about the combination of Aldred and RFC 1692.
`Slide 10, please?
`Aldred discloses software that can be installed on most computers
`that it calls nodes. And this is to enable the sharing of data between each of
`the nodes in the system.
`It provides what Aldred describes as a collaborative working
`environment.
`Now, Aldred discussed some examples of the types of applications
`that can use the Aldred system, such as shared drawing surface, chalkboards
`and chat rooms.
`But, it says it can support essentially any multi-user application.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`6
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`You can run it on existing personal computers and it runs over
`existing communication networks.
`Slide 11, please?
`Aldred works by installing what it calls a support system on each
`node. It's a software program that enables applications to share their data.
`Aldred calls the collection of application sharing their data on these
`nodes a sharing set. Here, this is from Figure 3 of Aldred. We've
`highlighted in yellow these logical pipes or channels that connect each
`member of the sharing set.
`And, in Figure 4, we've highlighted the collection of sharing sets
`members that are sharing data from each other.
`Let's go to slide -- or hold there.
`So, now, we get to the combination. In Aldred, hosts in the sharing
`sets send data to -- I'm sorry, let's go to slide 15.
`Petitioner's patentability challenge for the independent claims
`focuses on Aldred's group messaging capability called serialization. For
`some applications in Aldred's system, it's important that each application
`receive the same sequence of updates. This allows the application to
`remain consistent among each of the nodes.
`Aldred's serialization functionality is made possible by this central
`point called a central serialization point or CSP. It sends data to every
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`7
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`member of the sharing set and that way, every member of the sharing set
`gets the same sequence of data.
`Now we switch slides.
`Aldred's serialization functionality is depicted here in Figure 19 in
`Aldred. What it shows is data being sent from Application B to the central
`point and the central point then distributes that data to each of the members
`of the sharing set.
`The green highlighted channels there are the channels, the logical
`pipes that transmit data from one node to another.
`So, now, let's get to the combination that in Aldred, the central point
`sends data to each of the members of the sharing set. What it does not
`expressly disclose is aggregating that data.
`But aggregation is expressly disclosed and our secondary reference
`RFC 1692.
`And to understand why one would naturally combine Aldred with
`RFC 1692, let's take a look at how Aldred deals with networking.
`Slide 14, please?
`Aldred's approach is flexible and it supports different networking
`technologies. It uses what it calls link support modules to achieve this
`flexibility.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`8
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`Link support modules are basically a piece of code that are
`replaceable.
`In this instance, Aldred is specifically identified TCP/IP as one
`example of link support module that it can support.
`We pointed to this in our petition on page 37.
`Let's go to slide 15.
`JUDGE EASTHOM: So, is TCP/IP, is that different than TCP or is
`it a hybrid of TCP?
`MR. BORDER: I think TCP/IP is sort of a common way of
`describing the two layers, the transport layer and the network layer. I think
`they are commonly used together.
`There's also UDP which is a different type of transport layer. They
`aren't the same thing. TCP is sort of in this OSI stack, it's at the transport
`layer. IP is at the network layer, the two different layers of the
`communication stack. They're not the same thing.
`Let's go to -- we're at slide 15.
`RFC 1692, now this is our secondary reference. It's called transport
`multiplexing protocol. What it does is it multiplexes multiple payloads,
`multiple -- sorry -- multiplexes payloads from multiple IP packets into a
`single IP packet.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`9
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`As we've demonstrated in our petition and in our reply, this is the
`concept of aggregation.
`It also provides an express motivation to be used -- to use this
`multiplex and multiplexing techniques to enhance IP systems like that one
`disclosed in Aldred.
`It explains here at the top that it can enhance or improve network
`utilization, also reduces overhead for the processing of packets at the various
`nodes.
`
`So, we have a primary reference in Aldred that expressly teaches the
`use of TCP/IP. And it tells us that we can modify that networking
`implementation without affecting or negatively affecting the rest of the
`Aldred system.
`And we have a secondary reference, RFC 1692 the describes an
`enhancement to IP and identifies an express motivation why one of skill
`would want to use that technique with TCP/IP or in systems like Aldred.
`Let's go to slide 19, please.
`Patent Owner pushes back on this combination and it has one
`primary argument with respect to that.
`Let's go to slide 20.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`
`
`
`10
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`And, its primary argument has two parts. First, they argue that
`Aldred serialization requires data to be received by applications in the same
`order. There's no dispute there, we agree.
`As we discussed earlier, that is the point of Aldred's serialization.
`Patent Owner's error is in the second part of their argument. They
`allege that RFC 1692's TMux protocol would break that order because large
`packets may be sent ahead of smaller packets being aggregated, but that's
`not correct.
`TMux does not reorder packets, as I'll explain in a moment.
`Slide 21, please?
`Let's talk about how TMux works. There's no dispute here that
`TMux aggregates small packets in order. That's not the root of Patent
`Owner's argument.
`Patent Owners argue, instead, was based on a hypothetical. It a
`TMux -- if the TMux protocol encounters a large packet, that packet may
`skip a multiplex message under construction and be sent first. But that's
`actually not what the reference says.
`Patent Owner's argument stems from the top two call outs, those are
`on page one of the RFC protocol, RFC 1692 protocol, page 7.
`What they don't discuss is what's disclosed on pages 8 and 9 of RFC
`
`1692.
`
`
`
`11
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`That section says, acknowledge that some large packets may not
`normally be multiplexed. However, it explains that if a message is already
`under construction, that large packet is attached to the back of the multiplex
`under construction and then immediately sent.
`JUDGE EASTHOM: But, if the buffer's too small, how could it do
`
`that?
`
`MR. BORDER: Well, our expert was asked this at his deposition.
`And what he said was, if the buffer's too small, the message will be -- the
`TMux message under construction will be sent and then the large packet will
`be sent immediately after that.
`JUDGE EASTHOM: Okay.
`MR. BORDER: Yes, go -- can you go ahead and pull that back up?
`This is from slide 22. This is from Exhibit 2005, page 52 line 10 to
`5313. And this is where -- one of the places where our expert during his
`deposition explained that the smaller messages that were TMux under
`construction would be sent before that large packet.
`Let's go back to slide 21, please.
`But even if you ignore what RFC 1692 says about how it constructs
`packets, Patent Owner's argument still fails for three reasons.
`Slide 23.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`12
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`The first is Aldred would fix it. Aldred explicitly says that it
`delivers packets in the order in which they were since, which we've
`underlined in red. This is from our reply, page 5. And this is in Aldred on
`page 6.
`Patent Owner assumes that any reordering done by RFC 1692 would
`break this characteristic but they don't say how. They certainly don't
`challenge this -- they certainly have not alleged that this is not enabled. So,
`this is one way that, to the extent you did believe that RFC 1692 reorders
`packets, Aldred would fix it.
`Slide 24, please.
`The second reason their argument fails is because our petitions relied
`on Aldred's TCP/IP embodiment. Our combination would modify that
`embodiment to use the TMux enhanced version of IP.
`JUDGE EASTHOM: Can you repeat that, please? As that's
`critical and I want to --
`MR. BORDER: So, can you go to -- let's go to slide 25.
`In our petition, we relied on the embodiment described in TCP -- or
`the embodiment described in Aldred where it uses that link support module,
`the TCP/IP link support module that I discussed earlier.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`
`
`
`13
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`This is in our petition on pages 36 and 37, and 39 where we discuss
`that we were -- the combination we were considering was Aldred's use of
`TCP/IP in combination with the RFC 1692 methods.
`And, just for the record, that is slide 25 where we call out that
`information.
`Let's go back to slide 21.
`JUDGE EASTHOM: Now, Patent Owner is saying that you shifted
`your position somehow because you were talking about packets earlier in
`your petition, but now, you're talking about segments. Is that -- that's -- I'm
`not sure I understand the argument.
`Could you address that, please? Or how do you understand?
`MR. BORDER: Well, that's a good question, Your Honor. And,
`I'm not sure I understand that argument, either.
`What I think that Patent Owner was doing was trying to concede that
`we had not ever mentioned TCP packets before or TCP segments before, or
`we had not considered TCP in our combination.
`I think that was the root of their argument.
`But, our reliance on TCP here is simply rebuttal evidence to their
`argument that a person of ordinary skill would not combine RFC 1692 with
`Aldred.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`14
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`It's not part of our prima facie case of obviousness. The claims
`don't require any special order. It's just rebutting their argument that RFC
`1692 would essentially make Aldred inoperable.
`JUDGE EASTHOM: Oh, I see, the claims don't require the packets
`to arrive in order, is that what you're saying?
`MR. BORDER: No, they don't, Your Honor.
`JUDGE EASTHOM: Okay.
`MR. BORDER: Our reliance or sort of the subsequent discussion
`that is involved here is based solely on or is rebuttal to the idea that RFC
`1692 would somehow break the Aldred system.
`JUDGE EASTHOM: The common element.
`MR. BORDER: Right.
`JUDGE EASTHOM: I understand.
`MR. BORDER: And, as we've shown, first of all, we don't need
`TCP/IP because Aldred would fix any ordering. That, notwithstanding the
`fact the RFC 1692 doesn't actually reorder.
`JUDGE EASTHOM: Well, you need the TMux for the aggregating
`stuff, don't you?
`MR. BORDER: Absolutely, and we do.
`JUDGE EASTHOM: Okay.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`15
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`MR. BORDER: Yes. And, as I mentioned, TMux is an
`enhancement of the IP protocol. So, it would work hand in hand with IP.
`JUDGE EASTHOM: So, would that be the layer above the layer, I
`mean, I'm trying to get this straight. The -- in Aldred, you have the
`application layer that you say keeps the packets in order.
`And so, this transport layer would be under that?
`MR. BORDER: That's right. Aldred would pass down to the
`TCP/IP stack, its aggregated or its serialized packets. Those would be
`wrapped in a TCP -- sort of wrapped as TCP segments. That is passed
`down to the IP layer. That's where the aggregation occurs. Those are kept
`in order. They're sent out as an IP datagram and they're received by all the
`nodes in the network in the same order in which they were serialized.
`JUDGE EASTHOM: So, where the 1692 -- the RFC 1692 refers to
`those as segments, you're saying that those are packets? Is that --
`MR. BORDER: Well, no, Your Honor. So there is a such thing as
`a TCP segment, and that's what -- that is what you call the sort of payload of
`information that comes from the TCP layer.
`That goes down into the IP layer and those get wrapped in an IP
`header, for example. And that becomes and IP packet where I think RFC
`1692 calls it an IP datagram.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`16
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`The point about -- so, back to RFC 793, the point about this, and this
`is not disputed, is that RFC -- that TCP would fix any reordering issue. It
`assigns sequence numbers to each of these segments.
`Patent Owner's expert agrees with that and the patent itself at column
`11 -- I'm sorry, at column 3 line 41 to 53, they discuss RFC 793 and how it's
`used to ensure in order delivery.
`JUDGE EASTHOM: So, it would fix even the large packet
`problem?
`MR. BORDER: Absolutely, because it -- because it's above the IP
`layer, its assigned sequence numbers at that layer. So, no matter what order
`they get put in at the RFC 1692 level or the IP level, they would be sort of
`reassembled at the destination node based on the sequence numbers and the
`TCP sequence numbers.
`Let's go to slide 26.
`The final point on this order argument, even if you were assuming
`one that RFC 1692 reordered which, again, we -- the express language says
`that it does not, and even if you assumed that the TCP did not also
`reassemble these packets or assume that Aldred did not reorder or keep the
`proper order, there is no dispute that there is no reordering of -- in RFC 1692
`of small packets.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`17
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`And Aldred certainly encompasses small packet systems. For
`example, we pointed to its broad disclose of things like mirroring an existing
`application when no chat program chalkboard where people would just share
`information that -- and those type of things -- those type of applications as
`we explained wouldn't have this large application problem.
`Patent Owner's argument is that because some embodiments of
`Aldred may have large packets, that shows non-obviousness, but that's the
`law, Your Honor.
`Prior art must be considered for all it teaches. Aldred is not limited
`to systems that use large packets. It clearly discloses systems that use small
`packets. And Patent Owner doesn't dispute that those systems would satisfy
`the claims.
`Let's go to the final dispute, and this is over the construction of
`aggregated message and aggregated payload.
`Slide 34, please.
`Let's go to slide 35.
`Initially, we don't agree with Patent Owner, the construction that
`Patent Owner proposes. We think the Board should give these terms a plain
`and ordinary meaning.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`
`
`
`18
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`There is one relevant dispute and that's whether there is some sort of
`limitation as to the number of transport layer headers for these specific claim
`terms.
`
`As we demonstrated in our reply, this transport layer or header
`requirement is not the plain language of the claims, it's not supported by its
`specification. And, you know, it's no coincidence that this is the limitation
`that they've offered.
`The transport layer header, that doesn't appear anywhere in any of
`the challenged patents. That language appears in our prior art reference, the
`only place you'll find anything about transport layer or transport layer hears.
`Let's go to slide 36.
`Patent Owners have litigated these patents for, well, since 2007.
`But this is the first time that they have argued for this transport layer header
`requirement. And it occurred only after seeing our petitions that we filed in
`August 2017, September.
`Let's move to slide 37, please.
`The first point I want to make about these claim constructions, is
`there is no basis in the claim language itself for these terms. The claims say
`exactly what an aggregated payload is, for example. It's created by
`aggregating the payload portions.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`19
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`Aggregating message is created by aggregating the aggregated
`payloads.
`These terms, payload and aggregating and message don't have
`special meanings, they're generic terms.
`Patent Owner's arguments for these terms relies, if we can go to slide
`42, Patent Owner's arguments for these terms relies on the preferred
`embodiment, but not even the preferred embodiment supports the
`construction.
`For example, and this is slide 42, this is a call from the patent in the
`call out -- the lower call out.
`It relies -- Patent Owner relies on the specifications disclosure of a
`transport level protocol or TLP for its proposed transport layer requirement.
`But those aren't the same things.
`Transport layer protocol is not the same thing as a transport level
`protocol or TLP.
`Let's go to slide 43.
`The 523 patent gives two examples of a TLP, the transport level
`protocol. The first is IP. IP, as we discussed earlier, is a network layer
`protocol. And if the claims required removing a network layer header,
`there's no dispute that RFC 1692 does that.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`20
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`It aggregates by removing IP headers, combines it into a single IP
`packet, and we demonstrated this in our reply on pages 18 and 19.
`JUDGE EASTHOM: And then, it just sends one IP header, is that
`correct?
`MR. BORDER: That's correct, the RFC 1692. So the IP --
`JUDGE EASTHOM: And then, what are the header -- the mini
`headers that are embedded in there? Those are the --
`MR. BORDER: Those are transport mini headers.
`JUDGE EASTHOM: Okay. And they're the level headers that the
`Patent Owner says is excluded by the claim construction?
`MR. BORDER: Well, it appears what Patent Owner is arguing is
`that those transport layer headers or those mini headers are the same thing as
`a transport level header in the patent, but they're not the same thing as I'll
`show you in just a moment.
`The second, well, for example, right here, it says a TLP could be IP.
`An IP is certainly not a transport layer protocol.
`They also say TLP can also be TCP/IP. That's a combination of a
`network and a transport layer protocol.
`So, the point here is that nowhere in the patent does -- is the TLP
`described as being a transport layer protocol. This is confirmed by their
`expert, if you go to slide 44.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`21
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`I asked him whether transport level protocol is the same thing as a
`transport layer protocol. He said he didn't know, he had no opinion about
`that.
`
`Slide 45?
`I asked him whether, as the patent expressly states, whether a TLP
`can be IP? And, he says, here, this is from Exhibit 1052 of Case 79, line 21
`to page 80, line 15, and we talked about this in our reply at pages 17 and 18.
`What he said was the patent can characterize a TLP in any way that
`it wants. This is a coin term.
`So, and the only examples that this coin term has in the patent is IP
`or TCP/IP. There's no example in the patent of a TLP being just a transport
`layer protocol.
`Let's go to 46.
`Patent Owner also makes a disclaimer argument that says --
`JUDGE EASTHOM: Do you mean as there's no discussion of it as
`being a transport level protocol. I'm sorry, I'm getting the terms mixed up.
`MR. BORDER: Well, that's right, Your Honor. Can you go back
`to -- this was slide --
`JUDGE EASTHOM: You said layer, did you mean level or did I --
`MR. BORDER: It's slide 42. This is where the confusion is. The
`patent discusses a transport level protocol. It doesn't discuss -- in referring
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`22
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`to this, the headers that are removed, for example, and disclosed in the
`preferred embodiment, it never discusses the removal of a transport layer
`protocol. They're not the same thing.
`If you go to the next slide, this is slide 42, again. It says a TLP can
`be binding. IP is a network layer, it's not a transport layer protocol, TLP is
`not the same thing as the transport layer protocol.
`JUDGE DANG: Excuse me, does the patent at all discuss the
`transport layer at all?
`MR. BORDER: It briefly discusses the transport layer in the
`context of describing an OSI model. But, when it goes to the preferred
`embodiment, it only refers to TLP, transport level protocol.
`So, it was clear the Patent Owner knew the difference between the
`OSI model, the layers of the OSI model, the network layer, the transport
`layer. But they chose not to use that, instead, they used this coin term, TLP
`which is -- which appears to be a broader, and we'll cover things, both like a
`network layer and a transport layer -- or a transport and IP layer, I'm sorry,
`network layer, excuse me.
`Let's go back to slide 46.
`Patent Owner makes a disclaimer argument.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`
`
`
`23
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`JUDGE EASTHOM: So, are you saying their disclaimer is just too
`broad? Is that what you're saying? In other words, they, if anything, they
`could exclude the TLP, but they can't exclude the whole level?
`MR. BORDER: Well, we don't think this -- whatever statements
`are in their patent, we don't think that rises to the level of disclaimer.
`JUDGE EASTHOM: But, I mean, I'm assume if -- assuming it did,
`is that why your argument here is about the distinction between level and
`layer, is that --
`MR. BORDER: That's correct, Your Honor. There is no -- can
`you go to slide 48? This will help us see what one of the issues is.
`The only -- like the two sections that they cite as this possible
`disclaimer refer to message headers. They don't even refer to TLP headers.
`They don't refer to transport layer headers, they simply broadly say, it would
`be nice if you could remove message headers.
`That does not rise to the level of a disavow or a --
`JUDGE EASTHOM: But all their embodiments do remove lower
`protocol headers, is that right?
`MR. BORDER: The embodiments in the patent do discuss
`removing TLP headers. But as the Board noted, can you go to slide 49,
`please -- as the Board noted, even in their preferred embodiment, their
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`
`
`24
`
`
`
`Case IPR 2018-00129 (Patent 5,822,523)
`Case IPR 2018-00130 (Patent 5,822,523 C1)
`Case IPR 2018-00131 (Patent 6,226,686)
`Case IPR 2018-00132 (Patent 6,226,686 C1)
`
`message includes a number of transport headers, things like source support
`and other things that would need to be processed.
`So, while they do appear to remove a TLP header, it does not appear
`that they remove all transport headers, as the Board noted in their institution
`decision on page 12.
`Let's go back to 48.
`Now, if the Board were to find that this rises to the le