`
`
`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
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
