`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SAMSUNG ELECTRONICS CO., LTD.
`AND GOOGLE LLC,
`Petitioner,
`
`v.
`
`IRON OAK TECHNOLOGIES, LLC,
`Patent Owner.
`____________
`
`Case IPR2018-01552 (Patent 5,699,275)
` Case IPR2018-01553 (Patent 5,699,275)1,2
`____________
`
`Record of Oral Hearing
`Held: November 4, 2019
`____________
`
`
`
`
`Before SALLY C. MEDLEY, PATRICK R. SCANLON and
`ARTHUR M. PESLAK, Administrative Patent Judges.
`
`
`
`
`1 This Transcript addresses the same issues in the inter partes reviews listed
`above. Therefore, we issue one Transcript to be filed in both cases. The
`parties, however, are not authorized to use this style of filing in subsequent
`papers.
` Google LLC, who filed petitions in IPR2019-00110 and IPR2019-00111,
`has been joined as a petitioner in the respective proceedings.
`
` 2
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`JOSEPH PALYS, ESQ.
`Paul Hastings, LLP
`875 15th Street, N.W.
`Washington, D.C. 20005
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`ALBERT DEAVER, ESQ.
`McAughan Deaver PLLC
`550 Westcott Drive, #375
`Houston, Texas 77007
`
`
`
`
`The above-entitled matter came on for hearing on Monday, November
`
`4, 2019, commencing at 12:59 p.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`2
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`
`P R O C E E D I N G S
`- - - - -
`
`BAILIFF: All rise.
`
`JUDGE MEDLEY: Please be seated. Good afternoon. This is the
`
`hearing for IPR 2018-01552 and ‘1553 involving U.S. Patent No. 5,699,275.
`At this time, we’d like the parties to please enter as counsel for the record,
`beginning with the Petitioner.
`
`MR. PALYS: Good afternoon, Your Honor. Joseph Palys for
`Petitioner and joining with me is my colleague, Phillip Citroen.
`
`JUDGE MEDLEY: Thank you; and for Patent Owner?
`
`MR. DEAVER: Good afternoon, Your Honors, Al Deaver for Patent
`Owner.
`
`JUDGE MEDLEY: Okay; thank you.
`
`MR. DEAVER: Thank you.
`
`JUDGE MEDLEY: Each party has 45 minutes total time to present
`arguments. Petitioner, you will proceed first and you may reserve some of
`your argument time to respond to arguments presented by the Patent Owner.
`Thereafter, Patent Owner will respond to Petitioner’s presentation and may
`reserve argument time for sur-rebuttal. Petitioner, do you wish to reserve
`some of your time?
`
`MR. PALYS: Yes, Your Honor. I’m going to shoot for a 30 minutes
`opening so, maybe 15 minutes; but, it’ll depend on the questions from the
`Board.
`
`JUDGE MEDLEY: Okay; sure. And then Patent Owner, would you
`like to reserve sur-rebuttal time?
`
`MR. DEAVER: Ah, yes; 15 minutes would be fine; thank you.
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`JUDGE MEDLEY: 15; okay; thank you. As a reminder, please refer
`
`to the slide numbers in your deck so that we may follow along. Also, please
`speak into the microphone at the podium so that all may hear. We would
`like to remind the parties that this hearing is open to the public, and the
`transcript will be entered into the public record of the proceeding. And at
`this time, Petitioner, you may proceed.
`
`MR. PALYS: Good afternoon. May it please the Board. As the
`Board is aware, these two matters involve 5 grounds. The ’1552 matter
`involves 3, and the ’1553 matter involves 2. And the prior art that stems
`across these two cases and these five grounds really relate to some primary
`references -- Sugita, Ballard, and Hapka. There are some obviousness
`combinations -- Hapka with Parrillo and Ballard with Shimizu.
`
`Now, as I will discuss today, and it’s evident from the record, we
`believe that the Patent Owner has really narrowed the questions and the
`issues that this Board has to address with respect to both of these matters;
`and I’m going to touch on that or try to, at least, during this proceeding.
`They touch on implied constructions or interpretations of certain terms in the
`claims and, in some instances, how that applies to the prior art that’s at issue.
`So, I’ve started at slide two -- sorry, I’ve already -- didn’t follow the advice
`of Her Honor. I’m going to move to slide 3.
`
`Now, before I jump in, I will just briefly touch claim 1. It’s no
`surprise; we know that claim 1 is a system claim, it’s not a method claim;
`and it requires three items: a manager host; a first mobile unit; and a second
`mobile unit. And each of these elements is operable to do something; and
`that’s clear from the language of the claims that you see here. The first and
`second mobile units are operable to do three things: receive the patch
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`message; create patch operating code by merging and switching execution to
`that patch operating code; and manager host is operable to initiate
`transmission and address the patch message.
`
`If we jump to slide 5, please -- now, as I mentioned, there are some
`claim interpretation issues, we think, more so from what the Patent Owner
`has raised from its Patent Owner response. From our perspective, the
`Petitioner’s perspective, as you can see on slide 5, Petitioner raised five
`terms and phrases for interpretation.
`
`If you turn to slide 6, you’ll see from the institution decision, the
`Board decided other than the two terms you see on slide 6, which is the
`merging and the address limitations, no other terms expressly needed to
`construction. And, I believe, that was mainly because Patent Owner did not
`really raise any issues in its preliminary response with respect to claim
`construction.
`
`Turn to slide 7, however, we’ll see that the Patent Owner, in its Patent
`Owner response did not expressly or formally -- if I can say that -- raise any
`claim construction definitions, but it did so through implications to its
`arguments in trying to distinguish the prior art. And, realistically, I believe,
`that one implied interpretation is found highlighted in bullet point 1 on slide
`7, which, in a sense, the Patent Owner appears to ask for a construction to
`change the operable to language for the second mobile unit such that if a
`second unit has already been updated by a patch message, it can no longer be
`a second mobile unit that is operable to do the things that are in the claim.
`
`And along the same lines, we believe that the Patent Owner is really
`raising some temporal aspects to the limitations in the claims that are not
`there; and in order to get to where the Patent Owner wants to go, the Board
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`would have to rewrite the claim, reinterpret it, and we think that would be
`inconsistent with the language of the claim, and inconsistent with the
`specification.
`
`And Patent Owner tries to leverage this implied construction
`realistically, but only for, from our perspective, it looks like to try to
`distinguish one of the prior art combinations, which is the Ballard
`combination. We don’t believe that this construction really touches on the
`Sugita and the Hapka grounds -- the Hapka being in the ’1553 matter. But
`as explained in our papers, it’s really a distinction without a difference
`because even if you follow -- for some reason the Board wants to even
`consider these implied constructions -- we believe that the prior art will still
`meet the limitations of the claims. Now, the specification provides some
`insight on here, and I’ll touch on it and, probably, we’ll get into more issues
`when we start talking about the actual grounds.
`
`If we turn to slide 8, you can see an excerpt from the ’275 Patent
`specification. The ’275 Patent explains that there’s really three ways how
`the manager host can address a mobile unit. One way is the broadcast
`message, meaning broadcast all at once to all mobile units; the second is in
`groups; and the third is individually, one at a time. And that’s explained in
`the specification.
`
`As a back drop, before I touch on the actual prior art grounds, I want
`to frame this up from the perspective of if you look at the Patent Owner’s
`implied construction about this idea that the second mobile unit that’s
`operable to do these three things can no longer be a second mobile unit if it’s
`already been patched, really goes against what you see in the specification,
`and it really causes a lot of confusion, you know.
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`I’ll give you some examples that I was thinking of when I was
`
`preparing for this hearing. In one instance -- in column 10 of the
`specification, it describes how the manager host can send a patch message to
`the (inaudible), or to a mobile unit, and in that column it explains how, in
`one instance, the mobile unit has to verify. Maybe it’s a checksum or
`something like that the patch message has actually been received and, so,
`therefore, an update can happen. But that might not be the case.
`
`So, there’s instances here where even the ’275 Patent specification
`explains when a manager host sends -- if you picture a manager host with
`the network and the mobile unit -- what happens under Patent Owner’s
`construction if you have a mobile unit that’s configured in the way that the
`claim requires -- it’s operable to receive the message; it’s operable to merge;
`and it’s operable to execute. If that transmission that’s sent, and there’s a
`transmission error, and it never reaches the second mobile unit, does that
`mean that second mobile unit is no longer operable so it doesn’t meet the
`limitations of the claim; but then the manager host tries again, and the
`transmission goes through that time so now it is operable.
`
`Put it on its end, what if the transmission was received but it wasn’t
`verified, like we see in column 10. So, it was operable to receive but it
`never really updated and it never really switched execution. Does that mean
`it’s no longer a mobile unit that’s operable according to the claim
`limitations? And these permutations keep compounding when you look at
`what the Patent Owner’s implied construction really comes into play. But at
`the end of the day, and we’ll start with Sugita, which I’m going to move to
`next, it really doesn’t matter because the prior art, absolutely, in Petitioner’s
`
`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
`
`7
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`viewpoint, meets each one of these limitations; and, especially, since we
`have very narrow issues that the Patent Owner has raised.
`
`So, let’s jump into that. -- if we can turn to slide 9, please. So, in and
`note, the ’1552 matter, you see, the question really raised from the Patent
`Owner’s papers is whether Sugita discloses the claim manager host, and, in
`particular, this addressing feature, and the second mobile unit; and the same
`with Ballard in view of Shimizu grounds. And, in fact, that’s the same
`position that you’ll see with respect to Hapka and Parrillo.
`
`Now, Patent Owner narrowing the issues that you see in their Patent
`Owner responses is for both these matters, they focus the issues that the
`Board has to really address on these issues; and in doing so, they,
`essentially, conceded to certain things. They’ve conceded that all these
`other limitations in the claim are taught by the prior art that includes the first
`mobile unit. They did not cross examine Petitioner’s expert. They didn’t
`introduce any rebuttal expert testimony. So, what we have in this record
`right now is unrebutted expert testimony from the perspective of the
`Petitioners. So, that’s supporting the obviousness position; it’s supporting
`what the state of the art and all the evidence associated with those exhibits
`are in this record; and even on the teachings of the prior art.
`
`What we have from Patent Owner’s perspective is, essentially,
`attorney argument relying on some, in some senses, of what the prior art is
`allegedly disclosing. And they didn’t really even challenge the basis of the
`obviousness positions that are in these grounds. You don’t see any argument
`about motivation, rationale, things of that nature. So, what we have here is a
`full record that we believe is ripe for a decision by this Board; but let’s talk
`
`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
`
`8
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`about these very narrow issues that the Patent Owner really presented for the
`Board.
`
`Again, let’s start at Sugita. So, let’s just jump to slide 11. Now, from
`Patent Owner’s arguments, we believe they have raised two issues, basically.
`Now, Sugita discloses this Group ID feature. The question is whether does
`Sugita’s use of this Group ID feature meet the manager host operable to
`address the mobile units as it’s stated in claim one, and also for the
`Individual ID feature.
`
`Now, we represented in our reply that the Patent Owner kind of raised
`this issue on the Individual ID, but when you really look at their Patent
`Owner response, they really didn’t address that Individual ID argument.
`They really focused on the Group ID aspect, and then the use of a target list
`which was actually succumbed within the Group ID feature. It’s distinction,
`again, without a difference because I’m going to explain today, as our papers
`do lie, it doesn’t matter on how you view Sugita the prior art discloses this,
`these features in claim 1.
`
`So, we turn to slide 12, please. Now, I’m sure the Board’s aware, but
`I’ll just highlight that, Sugita discloses a method of updating mobile
`communication terminals; and these terminals, for example, and 1 through
`whatever in this network, are the mobile units that we see here. That’s
`undisputed. Now, Sugita explains in the beginning of the reference,
`somewhere starting around paragraphs 6, 7, 8, 9, 10 of the background of
`what are some of the problems and issues with the prior art and what Sugita
`is trying to address. And in order to address this, Sugita explains that it uses
`this Group ID feature where mobile units can be addressed in groups,
`multiple groups; and also in a stage approach where Individual IDs can be
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`used to follow up with making sure that we can try to update the mobile
`units that are in the network.
`
`Now, if we turn to slide 13, you can see, there’s a comparison here of
`the advantages that you see that the ‘275 Patent touts. Years later after
`Sugita touted very similar benefits and advantages of doing these types of
`mobile unit updating. It provides both for remote patching; they both
`provide for replacing code in a mobile unit so the code can be subsequently
`executed; they use a central location to do these updatings; and they also
`verify receipt when an update has been completed.
`
`So, let’s turn to the Patent Owner’s first argument, if you will on the
`Group ID feature. Turn to slide 14, please. So, what are Sugita’s Group ID
`features? Some excerpts from Sugita -- you’ll see on slide 14, from
`paragraphs 12, 13; and we’ll touch on 14, 15, and some other paragraphs in a
`second -- explains what Sugita means. There is, I believe, a disconnect
`between Patent Owner’s position and how they’re reading Sugita and what
`Sugita actually discloses; and, obviously, that’s Petitioner’s position. There
`is no doubt that Sugita explains that it can use multiple groups, in other
`words, Group IDs; and what does this mean.
`
`So, Sugita gives an example that -- let’s say you have 1,000 vehicles
`in a fleet, all right, and it has these mobile units. Sugita can separate these
`units up into groups, individual groups, and so you can address and update
`the units in a group separately from other groups. Now, it might stage walk
`through these groups that, eventually, get to try to update the mobile units;
`but they are multiple groups. And you can see that right here in paragraph
`12 where we’ve highlighted, and it says updating a plurality of mobile
`communication terminals in group units, plural. And, again in paragraph 13,
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`you can see how it’s highlighted in yellow and then, eventually, in blue,
`where it’s saying based on the Group ID of each group unit addressed to all
`the units or to units residing in specified groups. That’s how Sugita can
`walk through its process of attempting to update these mobile units.
`
`Why does that matter? Because we believe that Patent Owner’s
`position in its papers was making an argument that Sugita discloses you send
`out an update request to all of the mobile units at one time. So, even if that’s
`true, which we don’t think is really relevant to the claim -- let’s chew on that
`for a second. So, the fact that, and this is presented in our papers, that Sugita
`discloses that you can have multiple groups, it’s clear that when Sugita -- the
`base station which is the manager host -- again, no dispute on that -- will
`address mobile units in a single group, is not addressing mobile units in
`other groups.
`
`JUDGE MEDLEY: So, their argument is that it’s more of a broadcast
`message to all the groups; you think that’s what they mean?
`
`MR. PALYS: I believe so; and I saw that in their papers and even in
`the demonstratives that we’ll see today where they’re saying Sugita updates
`all the units. Now, that’s a key term I want to make sure this Board
`understands. So, I’ll backtrack a little bit and explain to you how it actually
`works.
`
`Sugita uses this Group ID feature to address these issues that it
`explains in paragraphs 7 through 10, and it’s the stage approach. So, it
`identifies -- let’s use the 1,000 vehicle example -- you can separate these
`1,000 vehicles into separate groups. You start at group 1 and you handle
`this process of addressing or trying to send out a Group ID to all of those
`units in that first group, okay. Sugita’s very clear -- and you can actually
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`switch to slide 15 too, just to hammer down the fact that there’re multiple
`Group IDs.
`
`Sugita’s very clear that not all of those units may be actually updated,
`okay. They may be addressed; they may be, let’s try to send to you Judge
`Medley, I want to send to you an update. You may not receive it; and
`Sugita’s very clear on this. In paragraph 36 of that reference it even gives
`you a good explanation. What happens is each of these units in that group
`unit will send a response back when it has completed its update. That’s in
`paragraph 36 of Sugita. Meaning that there are instances where some of
`those units in that first group may not have been updated. So, what does
`Sugita do?
`
`Sugita brings in this Individual ID and what -- if you turn to slide 16, I
`believe; yes -- Slide 16 shows in paragraphs 12 and 13, again, if the
`remaining terminals, the remaining mobile units that were never updated are
`now addressed one at a time. You can see that highlighted in paragraph 13.
`So, there’s two ways, as our petition lays out, where Sugita can meet this
`limitation of the manager host addressing the first mobile unit and not the
`second mobile unit; and it’s through Group IDs. The first point is that the
`manager host that’s addressing any of these mobile units in the first group
`but not in the second group, that meets that limitation. And the second part
`is, even in the individual stage where it serves to do one at a time, where I’m
`going to specifically address one mobile unit, at that time it’s also doing the
`same feature of what the manager host is -- and I repeat -- operable to do
`something, okay. And you’re going to -- we’re going to probably touch on
`this a little bit. Now, the claim 1 is very clear you have to have these
`
`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
`
`12
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`elements that are operable to do something, doesn’t actually have to do it. It
`just has to be capable of and operable to; and Sugita actually discloses that.
`
`JUDGE MEDLEY: So depending whether it’s broadcast to a group,
`the patch is sent to a group and then, you know, you acknowledge that you
`didn’t receive it, and then it’s transmitted to that individual one. I
`understand that their argument is that because the second mobile unit has
`already received it, it’s not operable to receive then the second time that it’s
`sent, is that it? Is that an accurate characterization?
`
`MR. PALYS: Right. I think of their argument and, I think, that
`argument might apply to most of the other prior art; and, we think, that’s
`wrong. I want to say -- first, if you can pull up the Patent Owner response,
`please, Phillip? And I’m going to touch on that point. The Patent Owner’s
`made a few concessions here on this point; and, I think, that it kind of
`unravels their argument.
`
`Now, again, look at claim 1. Claim 1 requires a first mobile unit
`that’s operable to do three things, right: receive; merge; and add, or execute.
`The second mobile unit uses the exact same language, it’s operable to do the
`exact same three things; and the manager host is operable to initiate, and
`then do this addressing thing. It just means that those three elements in that
`system, claim 1, you have to have a mobile unit that is operable to receive it.
`And, I think, if you turn to -- can you go to Patent Owner’s response at 13 --
`and I understand that the remote Judge might not have this on the screen and
`may not be able to see this, but I’ll do my best to (inaudible).
`
`JUDGE PESLAK: Did you say page 13?
`
`MR. PALYS: Yes, sir, page 13. I’m going to be looking at the first
`paragraph, starting around line 4. So this is the Patent Owner --
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`JUDGE PESLAK: (Inaudible).
`
`MR. PALYS: Yes; sure. This is the Patent Owner making argument
`
`with respect to Sugita; and they’re acknowledging where Sugita has this
`example. You can have the 1,000 cargo transport vehicles described by
`Sugita that need updating. In other words, rather than starting by
`transmitting and update the 1,000 individual terminal ids, Sugita’s process
`could start with, for example, 20 group units. So, first off, there’s a
`concession right there, which we think you have to because that’s what
`Sugita teaches, multiple group units. So, there are two ways that we
`presented how Sugita teaches this addressing feature is send the update to
`units in one group and not the other. Third, in their Patent Owner response it
`seems that they were suggesting that there was just one group and that’s not
`the case; and they kind of admit that in their Patent Owner response.
`
`But to get to your point about the operability, if you turn to the bottom
`of page 13, you can see another interesting statement here. Here, they’re
`quoting paragraph 13, and Patent Owner admits that the emphasized portion
`above is consistent with the disclosure that all mobile units, all mobile
`terminals, capable of being updated or sent the updated information. And
`they say the same thing on pages 15 and 17, something along the same lines
`-- if we jump down to 15. I believe it’s at the bottom, yeah. Sugita discloses
`sending update information to all mobile communication terminals that are
`operable to update current operating code.
`
`Now, what does that mean? Why is that relevant? Sugita has -- let’s
`take the Group ID unit as an example -- the fact that it sends or tries to send
`the update, okay, to these mobile units does not mean that -- let’s say the
`first mobile unit receives that update which Sugita discloses; it confirms it,
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`sends it back to the base station; merges it with its current operating code;
`and executes it. That’s fine; that can be the first mobile unit. The fact that
`another mobile unit, even within that group may have been addressed or an
`attempt was to send that to that mobile unit, doesn’t mean that mobile unit
`wasn’t operable to receive it. It doesn’t mean that it wasn’t operable to
`update it, or merge, and execute.
`
`To get to you example, Judge Medley, where you said well what
`happens if it received it already? Well, again, the claim requires that the
`mobile units be operable to receive, operable to merge, operable to update.
`The fact that it may have received it and didn’t update it, it still -- if anything
`that shows that mobile unit was operable and is operable to do that. The fact
`that some mobile units may not have received it -- remember the example
`that I said about the ’275 Patent specification, what if there’s a transmission
`error. Is that automatically some temporal base or some event change what
`that mobile unit is, how its configured, what it’s operable to -- it doesn’t.
`And no matter how you slice Sugita in terms of the Group IDs, if you’re
`sending to mobile unit one group and not another group, Sugita’s very clear
`that at the end of the day, they’re trying to update all of the terminals at
`some point, but they follow this process. And that claim 1 only requires a
`first mobile unit that’s operable to receive, operable to merge, operable to
`execute. They don’t dispute that. That’s not disputed in their papers that
`Sugita teaches that first unit.
`
`And in our petition, we explained how Sugita discloses that each of
`these mobile units are configured in the same way; and, in fact, that’s what
`Sugita wants to do, wants to send that update to all of these mobile units in
`these vehicles, the same update. So, the other units that may have not
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`received that, or may not even been addressed, whether you’re using the
`Group ID feature -- more on point, the individual feature, the Individual ID -
`- just because another unit hasn’t been either addressed or it didn’t receive it,
`doesn’t mean it wasn’t operable to. And that’s laid out in our petitions, and
`that’s laid out by Sugita. We believe that Patent Owner’s position on this
`point is, basically, again, implied interpretation on the claim trying to make
`the claim say that you have to do something. In other words, you have to
`take the second mobile unit and somehow carve out what the language says.
`Where it says I have a mobile unit that’s operable to do x, y, and z -- the
`three things -- but not when blank, or maybe when it’s already been received
`or updated, or received and not updated. There’re all these conditions that
`they’re trying to put on there; and that’s not in the claim. The claim is very
`straightforward. What is required there is inoperable to the language, and
`it’s very clear from the specification, as I pointed out.
`
`So, in the end when we look at what Sugita has and what we disclose -
`- if you turn to slide 20, please -- the other argument that Patent Owner
`makes with respect to Sugita -- yes, this is it. Sorry, on slide 20 we take an
`excerpt from the second mobile unit, or the petition, to explain how we
`showed what a second mobile unit is. It touches on what I mentioned
`before, that they didn’t dispute our showings that the mobile units in Sugita
`can be the first mobile unit. Claim 1 regurgitates the same language for the
`second mobile unit, it’s just a label. You’re a first mobile unit; I’m a second
`mobile unit. You can flip the labels if you want, but we’re both operable to
`do these things, right. My phone is operable to make a call. Just because I
`don’t make the call doesn’t mean it’s not operable to do that, okay.
`
`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
`
`16
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`That’s the thinking that we see here in the claims; and what we had
`
`done in the petition is, obviously we relied on the teachings that you saw in
`our rationale and our disclosures for the first mobile unit because all the
`mobile units are configured and operable to in the same way. If you take
`those teachings from Sugita about what the mobile units are, how they’re
`configured, and how they’re programmed and what they’re supposed to do
`in the context of what Sugita is trying to accomplish, which is to send this
`update to all these units, take that context and you take it to the perspective
`of their process and what that base station is doing in the context of the
`claim manager host can that base station, is it operable to address one unit
`and not the other -- it sure is. It does it in the Group ID feature way, sending
`an update message to a unit in group 1 but not group 2; and it does it when it
`goes to the individual stage, sending an update to a very specific address
`mobile unit and not another. That’s what the claim requires and that’s what
`we have; and that’s exactly what’s in their own specification. The three
`ways that you can update broadcast groups and individual.
`
`JUDGE SCANLON: Excuse me. Is your position on that point then
`that Sugita never sends a patch message to the other groups, or the
`individual ones, or they just do it at a different time?
`
`MR. PALYS: I believe the latter; and if I could explain, Your Honor.
`
`JUDGE SCANLON: Sure.
`
`MR. PALYS: So, Sugita’s very clear on this. If we’re talking about a
`group, we just stick to one group in which it’ll get you down to the
`individual stage. Sugita starts with -- I should be looking here because I’m
`looking at the screen -- Sugita starts with the Group ID feature. Let’s take
`group 1, let’s send an update to, let’s assume the three judges on the panel
`
`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
`
`

`

`IPR2018-01552 (Patent 5,699,275)
`IPR2018-01553 (Patent 5,699,275)
`
`are in group 1. I’m going to send the update to each one of you. Judge
`Medley, you may not have received that. You did not send -- I’m the base
`station, I’m the manager host -- you did not send me an acknowledgement.
`But, Judge Peslak and Judge Scanlon, you did. So, I know you’re updated.
`So, you are operable to do all these things -- receive, you’ve updated your
`current operating code, and you’re executed; that’s fine.
`
`Now, Judge Medley, the fact that you, as one of the mobile units in
`that group, did not acknowledged that you either received it or updated it is
`clear; and Sugita, and again in paragraph 36, I believe, is very clear about
`this aspect, doesn’t mean that you weren’t operable to receive it; doesn’t
`mean that you weren’t operable to execute that, and merge that. Now, what
`Sugita does, to get to your point, Judge Scanlon, is it will then shift to -- it
`keeps a list, it keeps a running list; and once there’s a certain number of
`units that didn’t get updated or have been updated, rather -- it shifts to an
`individual addressing feature. Meaning, all right, we’re not going to use
`Group IDs anymore, now we’re going to go