throbber
U.S. PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`EMERSON ELECTRIC CO.,
`Petitioner,
`
`v.
`
`SIPCO, LLC
`Patent Owner.
`____________
`
`Case IPR 2016-01895
`Patent 7,697,492 B2
`____________
`
`Record of Oral Hearing
` Held: December 19, 2017
`____________
`
`
`
`
`
`Before BRYAN F. MOORE, MICHAEL J. FITZPATRICK, and ROBERT
`J. WEINSCHENK, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`
`
`
`
`
`
`JAMES L. DAVIS, ESQUIRE
`JAMES R. BATCHELDER, ESQUIRE
`CAROLYN L. REDDING, ESQUIRE
`Ropes & Gray, LLP
`1900 University Avenue, 6th Floor
`East Palo Alto, California 94303-2284
`(650) 617-4000
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`
`
`
`
`
`
`
`
`
`GREGORY CONSALVES, ESQUIRE
`Gonsalves Law Firm
`2216 Beacon Lane
`Falls Church
`Virginia 22043
`(571) 419-7252
`
`THOMAS WALLEN, ESQUIRE
`Meagher Emanuel Laks Goldberg & Liao, LLP
`One Palmer Square, Suite 325
`Princeton
`New Jersey 08542
`(609) 454-3500
`
`
`The above-entitled matter came on for hearing on Tuesday, December
`
`19, 2017, commencing at 1:36 P.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`2
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`
`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
`
`P R O C E E D I N G S
`- - - - -
`JUDGE MOORE: Good afternoon.
`MR. BATCHELDER: Good afternoon.
`JUDGE MOORE: I'm Judge Moore. With me today are Judges
`Weinschenk, and by remote Judge Fitzpatrick. We have a couple of
`hearings that we separated out this afternoon, so we are going to start
`with the hearing in Case IPR 2016-1895. That hearing will run for
`approximately an hour, and then will be immediately followed with --
`we'll probably take about a five-minute break in between -- then we'll
`follow with the hearing in IPRs 2017-00007 and 00008.
`So, I'm turning to 1895. Each party will have 30 minutes time to
`present their arguments, the Petitioner bears the burden. The Petitioner
`will go first, the Petitioner can reserve time, if they wish, then the Patent
`Owner will present their arguments.
`A reminder that we have a Judge that's remote, so if you are using
`demonstratives, please point out the number of the slide you're on, and if
`you're referring to evidence that's not on a demonstrative, give some time
`to make sure the remote Judge can catch up, and get to the place of
`evidence that you're discussing. And with that, let's get a roll call of who
`is here, starting with the Petitioner.
`MR. BATCHELDER: Good afternoon, Your Honors. May it
`please the Board? James Batchelder from Ropes & Gray, on behalf of
`Petitioner, Emerson Electric; with me are my colleagues from Ropes &
`Gray, Jim Davis and Carolyn Redding.
`JUDGE MOORE: And for the Patent Owner?
`
`
`
`3
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`
`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
`
`MR. GONSALVES: Good afternoon, Your Honor. My name is
`Dr. Gregory Gonsalves, and I'll be representing the SIPCO, the Patent
`Owner, and with me today is Mr. Tom Wallen.
`JUDGE MOORE: Okay. With that, unless there is anything from
`the other Judges, you may begin when you're ready.
`MR. MATCHELDER: Your Honor, if I may just --
`JUDGE MOORE: And before you begin. How much time do you
`think you'd like to reserve?
`MR. BATCHELDER: Depending on the Board's questions, we
`intend to reserve roughly 10 minutes.
`JUDGE MOORE: I'll let you know when we get to 10 minutes.
`MR. BATCHELDER: Thank you. And just a couple of
`housekeeping matters. One, we've handed the Court Reporter a hard
`copy of our demonstratives. And Judge Weinschenk, and Judge Moore,
`would you like a copy as well?
`JUDGE MOORE: Sure, we'll take one.
`MR. BATCHELDER: Thank you.
`JUDGE MOORE: You can approach. Thank you.
`JUDGE FITZPATRICK: Judge Moore, I can hear either Judge
`Weinschenk louder, perhaps than you. I'm wondering if some of the
`microphones --
`JUDGE MOORE: Am I better now?
`JUDGE FITZPATRICK: Can you repeat that?
`JUDGE MOORE: Am I better now?
`JUDGE FITZPATRICK: Yes, perfect.
`JUDGE MOORE: Okay, great.
`
`
`
`4
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`
`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
`
`JUDGE FITZPATRICK: Thank you.
`MR. BATCHELDER: And, Your Honors, I'm told that there is no
`mic on the lecterns, so if I'm not speaking loudly enough, please let me
`know. Thank you. Oh, we do have? Okay. So he says we are mic-ed up
`after all. Okay.
`So, again, may it please the Board? James Batchelder from Ropes
`& Gray on behalf the Petitioner; I intend to address the claim
`constructions issues for the 492 Patent, and Mr. Davis will address the
`prior art issues; so, if I might; and with the Board's permission, begin
`with the issue of scalable address, and ask the Board to turn to argument
`slide 7 in our demonstrative deck.
`And let me start out by saying that we believe that the Panel got it
`right in the institution decision, and say that in connection with an
`address, the specification uses the term "scalable" one time, and uses the
`term "scalabilty" one time, again, to describe an address. The word
`"scalable" is used in the passage that's quoted on the left in the slide, on
`the bottom, and the word "scalability" appears in the column 11. Lines 1
`through 4, referencing the scalabilty of the "to" address, and that's the --
`JUDGE MOORE: Counselor, let me just go ahead and stop you
`there. The Patent Owner points out another case, another couple of cases
`where the claim construction for, are pretty much the same or very
`similar claim term, with basically the same specification, and this issue of
`whether it is the address itself that needs to be scalable, I don't think, and
`you can correct me if I'm wrong, but I don't think was directly taken on in
`DI or in the briefing before the DI.
`So, the question is, what are we to do with this other case? You
`
`
`
`5
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`know, are we to be consistent with that case? This claim's construction is
`as I said, so the prior art doesn’t make a difference, it's the same spec.
`What am I to do with that? What are we to do with that?
`MR. BATCHELDER: The scalable address in that institution
`decision, it is inconsistent with this Panel's construction. It certainly is
`not binding on this Panel, and I submit, on behalf of Petitioner that that
`did not come to the reconstruction, and that this Panel did in this
`institution decision for the reasons that we agreed to, and that I'm
`prepared to explain here.
`There really is one specification passage that speaks to this
`question. Again, it's quoted there on slide 7, and it refers to "to" address,
`700, which is depicted in Figure 7, and further described in Figure 8.
`And this is the only passage that describes an address as being scalable,
`and it says, as you can see at the outset, "The "to" address, 700, can
`indicate the intended recipient of the packet, this address can be scalable
`in 1 to 6 bytes based upon the size and complexity of the system."
`And then it goes on to say, by way of example, "The "to" address
`700 can indicate a general message to all transceivers, to only stand on
`transceivers or to an individual integrated transceiver." And it goes on to
`give some more detail, and then it says in the last sentence, "The "to"
`address 700 can be scalable from 1 byte to 6 bytes, depending upon the
`intended recipients."
`So, I think the specification is quite clear about what it means here
`by a scalable address, it can expand in byte size, and it can do so, again,
`based on the size complexity of the system, and whether the message is
`designed to be sent to all transceivers in the system, a subset of them, like
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`only standalone transceivers, or to an individual transceiver.
`That's what the specification describes as a scalable address, and to
`the extent that this other Panel, which I think is a fair reading of it, which
`says that the scalable address of the claims is not just "to" address, I just
`don't think that's an defensible read, and I think it's inconsistent with even
`the positions that have been taken by the Patent Owner here.
`I would point that in the Patent Owner's briefing, and in their
`response paper, they did not cite this quoted passage. Again, the only
`quoted passage that speaks about a scalable address, nor did they cite the
`passage in column 11, lines 1 through 4 of consumer scalability of the
`"to" address, and they would simply ignore that passage. And that
`passage is exactly aligned with this Board's construction in the institution
`decision.
`I'll also point out on slide 8, that in a different proceeding, the
`Patent Owner did acknowledge the specification passages that I just
`mentioned that describes scalable addresses, and came to exactly to their
`conclusion that this Panel did. In the middle box here, on slide 8, the
`Patent Owner remits that scalable addresses, one, it can be varied based
`on the size and complexity of the system. It's exactly this Panel's
`(inaudible), and in the bottom box it says that it does not require that each
`individual address is scalable.
`JUDGE WEINSCHENK: Mr. Batchelder, the Patent Owner's
`construction here says that it requires that the address of the remote
`device be scalable, and I'm putting aside the specification for a moment,
`the claim says a scalable address of at least one remote device. So, isn't
`the Patent Owner's construction supported by the claim language?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`7
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`
`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
`
`MR. BATCHELDER: Your Honor, I think, turning back to the
`specification, I think that that's exactly what that passage in column 9,
`line 59, through column 10, line 4, is describing. It's at least one device
`because, yes, the "to" address could speak to one unique transceiver, but
`it also addressed the substantive transceivers, not all transceivers. So,
`this is a "to" address, it certainly is a receiver address, and it's referring to
`at least one device because it can cover all of those, and it's scalable in
`exactly that sense, so that's what this specification says what it means by
`that phrase.
`JUDGE WEINSCHENK: So, is the distinction here that Patent
`Owner is attempting to limit the address to just one device?
`MR. BATCHELDER: Exactly.
`JUDGE WEINSCHENK: Whereas you're saying the address can
`be for multiple devices?
`MR. BATCHELDER: That's exactly right, Your Honor. And
`that's exactly the point that we made in our demonstrative slide number 9.
`We think there are a couple of problems with the Patent Owner's
`construction here. One is, it uses the word scalable to define scalable,
`which is circular and unhelpful, but to your point, the language uses the
`phrase, "at least one remote device" and the Patent Owner's construction
`refers to "the remote device," and therefore it would leave out the
`possibility that columns 9 and 10 speak to about the "to" address,
`speaking to, for example, in a broadcast way to all transceivers in the
`system, or to a subset of them, and will require a unique address.
`And that is further problematic because other claims, claim 2 and
`claim 10, for example, use that phrase "unique address" and if that's what
`
`
`
`8
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`claim 1 had been meant to be delimited by, then of course claim would
`have said so using exactly that language.
`So, for all those reasons, in addition to the fact the Patent Owner's
`construction here is narrower than the construction that is laid out in slide
`8, in District Court case that was supposed to be under (inaudible), which
`is improper, and for all those reasons, we again submit that this Panel got
`it right, and that your claimed construction in your institution decision is
`the right one.
`Keeping time in mind, if I can move on to the scalable message
`that I will address in slide 10; and again we submit that the Panel got it
`right. Your construction was the message in which the size of the
`message was varied; this in the specification is directed again to Figure 7,
`but to the data box 770.
`And again, the patent speaks to the scalability of the data in that
`same passage at the top of Column 11 that I mentioned, and the Patent
`Owner attempts to delimit this as we addressed in slide 11, by adding on
`it can vary independent of other fields, and it makes that argument, based
`on a specification passage, that it cites column 10, line 37 through 47, it's
`exactly the same argument it made in its preliminary response, the Board
`took it head-on, and looked at that passage, and it said, and I've quoted
`that at the bottom here, "The Patent Owner's position is not supported by
`the above-quoted language."
`The above-quoted language merely states, and wants the size, and
`then it grows beyond 109 bytes, and will be divided into multiple
`packets, the quoted language is silence as to what happens and the data is
`smaller than 109 bytes. And it went on to say, "To the extent that there'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
`26
`
`
`
`9
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`embodiment here, varying and independent of other fields, there's been
`no lexicography or disclaimer to limit the claim in that way," and so that
`attempted addition of that claim limitation is improper for the very
`reasons that the Panel cited.
`Again, in the interest of time, just moving on them to the last claim
`construction issue, as it addressed in demonstrative 12. And this
`addresses the terms "remote device" and "remote wireless
`communication device." The Patent Owner -- well, I should say, the
`Panel, again, got it right by saying no construction is necessary. These
`are terms that have plain meaning.
`A Patent Owner attends to -- appends to the common
`understanding of a remote device, this limitation of it including a sensor
`or actuator that's inconsistent with the specification. Figure 2, for
`example, has both integrated transceivers and stand-alone transceivers,
`there's no basis, and the claim on the specification for adding that
`language, and the Patent Owner's only cited basis for it, is to point to an
`Amazon litigation involving a different claim language, in which the
`original data message comprised the sensor data signal. We don't have
`claim language like that here, and so this attempted limitation like the
`Patent Owner simply is defective.
`So with that -- unless the Board has further questions about the
`claim construction -- I will recede the podium to Mr. Davis to address the
`prior art issues.
`MR. DAVIS: The claim's subject matter in each of the challenged
`claims was well known before the 492 patent. It was well known to send
`packets among wireless transceivers in the wireless network, it was well
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`known to use scalable addresses, it was well known to use scalable
`messages.
`And turning to the Petitioner's slide 2, there are two different
`grounds here, this is what we refer to as the Johnson ground which
`involves bold anticipation and obviousness of several different claims,
`and then the Mason ground which is a combination of Mason, and
`several different other references stream.
`For each of these -- Can we turn back to slide 2? For each of
`these, there's only a couple of claim terms in dispute, and for each of
`those claim terms the Patent Owner's arguments really boil down to claim
`construction issues.
`And as Mr. Batchelder just explained, each of those arguments
`really fall of the Patent Owner's incorrect claim constructions. In
`addition to that, there is the motivation to combine the issue with respect
`to the Mason reference, which the claim will address each of those issues
`in turn.
`Turning now to Petitioner's slide 14, this is the first disputed claim
`term for the Johnson reference, scalable address. And really it's not
`disputed under the correct construction, nor under the Board's
`construction, the Petitioner's construction, the Examiner doesn’t dispute
`that Johnson discloses a scalable address, and that's not surprising,
`because that's quoted there in the middle part of the slide. Johnson
`expresses, it's disclosed in the destination address that's specified and
`expanding the byte in its address field.
`And Johnson's disclosure really goes further than that, and it's
`actually very similar, what's in the 492 patent itself, as excerpted there at
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`the bottom of the slide. You see the three different types of scalable
`addresses that are disclosed in the 492 patent that Mr. Batchelder just
`discussed, the concepts of broadcasting, as it's shown there in green,
`multicasting as shown in blue, and unicasting as shown there in orange.
`And turning to the next slide, slide 15, you'll see that Johnson has
`those same disclosures of varying the size of the address according to the
`(inaudible) broadcasting even inside of that, either using 8 bits, or 0 bits,
`and scaling that address -- scaling the address of even an individual
`device which would scale in that example in Figure 32, from 40 bits to 32
`bits, and that actually takes us to -- which would meet the limitations, and
`the Petitioner's and the Board's construction, but even under the Patent
`Owner's construction, if you can turn to slide 16, where they tried to
`limit, incorrectly, the scalable address to a particular device.
`And Johnson discloses that the presence or absence of the
`NSMTYPE portion of that address makes that scalable as well, as
`indicated both in Figures 32 and 43, the NSMTYPE portion of the
`address may or may not be used, thus making the size of the address,
`even for an individual device, scalable.
`JUDGE WEINSCHENK: But is the NSMTYPE portion related to
`a particular remote device?
`MR. DAVIS: Yes, it's used to back up -- Johnson discloses that
`you can use the NSMTYPE, you might only have one NSMTYPE for a
`sub-channel, or you might have multiple, so to be able to address an
`individual device, when there's multiple NSMTYPEs, you need that
`portion of the address, and then you need to add on the NSM-ADR, the
`NSM address on top of that to address an individual device. So, the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`12
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`answer is, yes, you do need that when there's multiple NSMTYPEs
`within a sub-channel.
`JUDGE WEINSCHENK: So, there's a situation in Johnson where
`the NSMTYPE would be included as part of the address for the particular
`device?
`MR. DAVIS: Correct, Your Honor. And that's really also
`expressed there in Figures 32 and 43 by labeling that whole portion as the
`address. So, if there are not any further questions on that limitation, I'll
`turn to the next disputed limitation of scalable message. This is on slide
`19, and it really uses similar figures, that network message field, as
`disclosed in Figures 31 and 32, can also vary by 8 bits. From 52 to 60
`bits or from 20 to 28 bits; again, making a scalable message, where it
`varies in size.
`The Patent Owner's argument I would expect, as it's termed on
`slide 20 is that it can't -- that it needs to vary independently of the other
`fields, that's a limitation that the Patent Owner is trying to read into the
`claims, it's not stated in the claims, anywhere. The Board considered this
`already, and came to the correct conclusion that it is scalable.
`If we can turn back to slide -- actually we can jump forward, unless
`there are any further questions on that limitation, to the remaining
`limitation in this field on Johnson, the remote devices on slide 22. And
`this just really boils down to the Patent Owner misunderstanding the
`Petitioner's proposed arguments here. The Petitioner is relying on both
`what are labeled the RCNs and the NSMs as shown there in Figure 1 of
`Johnson, as being the remote devices. The NSMs have sensors
`associated with them, and actuators associated with them, the RCNs and
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`the NSMs communicate with one another, thus meeting all the limitations
`related to the remote devices.
`JUDGE MOORE: In terms of the claim, you have two devices
`that work differently, reading on one limitation in the claim, is there not a
`problem with that, in terms of reading a prior art onto a claim that are two
`different devices reading in the same limitation?
`MR. DAVIS: The short answer is, no; there's no problem. The
`longer answer is that the claim recites plurality of the transceivers,
`remote devices, what have you, both of this group can satisfy that
`limitation. In fact, on slide 23, the 492 patent itself, as shown there, as
`column 4, lines 57 to 66, recognizes that the transceivers can differ, so it's
`already envisioned in the patent itself; that they don't have to be the same.
`If there aren’t any further questions on Johnson, I'll move on to the
`Mason ground, this is on --
`JUDGE WEINSCHENK: Actually, before you do, Mr. Davis.
`MR. DAVIS: Sure.
`JUDGE WEINSCHENK: I want to turn back to something. Could
`you move to, real quickly, if you go to slide 16 in your demonstrative?
`So, you were talking about how the NSMTYPE is part of the address,
`and I was looking to see where Johnson teaches this, and it looks to me
`like what you’ve got there is a cite from Mr. Kinney, which says, "If the
`system is larger and/or more complex, and includes multiple types of
`NSMs, the system can use a combination of NSMTYPE and NSM
`address as the address." Is that in the reference somewhere, or is that just
`Mr. Kinney's reading of the reference?
`MR. DAVIS: That is in the reference itself, Mr. Kinney is citing
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`passages of the reference, but those passages are further included at the
`very bottom of slide 16, and I apologize for the small type. I'm going to
`highlight one of them, but I think all of them apply. Column 41, lines 49
`to 53 says, and I'll quote, "Network service module addresses need only
`be unique within each network service module type, thus that an 8 bit
`field specifies NSMTYPE, and the NSM address base is potentially 256
`times of that shown in Figure 35," recognizing that it's scalable and
`interchanges with the size and complexity of the system. If you have a
`bigger system, you use the NSMTYPEs as additional address bits.
`If there aren’t any further questions about Johnson I'll move on to
`Mason. This is on slide 26, the first, this Figure is motivation to
`combine, Mason is being combined with particular teachings from three
`different references, and actually in this situation the combination is very
`straightforward, Mason expressly discusses each of these three
`references. With respect to the first of them, I'll start with -- from the
`right-hand side and move backwards.
`But Mason expressly relies on the C12.18 protocol to load data
`from the meters in Mason, which explains the first combination, turning
`to slide 27, Mason expressly references the Shuey disclosure, that
`actually shares similar inventors, and they were both opening at the same
`time, they are probably describing this automatic meter-reading system,
`and have very similar figures such as Figure 5 there, as shown on this
`slide. Again, that combination is straightforward.
`And on slide 28 you have the combination with EIA, or on specific
`teachings from EIA. EIA is that the (inaudible) have served, EIA was
`actually LonTalk, and that's as shown there in Mason on the top quote,
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`Mason expressly references LonTalk and says: that protocol can be
`employed. LonTalk is also made into EIA as recognized in a number of
`exhibits of record here. Exhibits 1022 to 1024, for example, they have
`very similar disclosures about the same disclosures.
`And Mr. Kinney further testified they are part of the same
`protocol, so that the combinations here, you need to look no further than
`Mason itself for the motivations on how it's straightforward and obvious
`to do that.
`I'll move on then to the first disputed limitation for Mason. This is
`on slide 33, scalable address, remember before we talked about the
`(inaudible) disclosure of broadcasting, and multicasting, and unicasting,
`it's using different numbers of bits or bytes, that same disclosure is as in
`Mason, address format, 0 for broadcasting is 1 byte, address format 1 for
`multicasting.
`Again uses 1 byte; unicasting, you can either use 2 bytes or 7 bytes
`as shown in the examples of formats 2A and 3, scaling the size of the
`address field, and even under the Patent Owner's construction on slide 34
`there's two different length and size address fields shown there in Figure
`36, a 2 byte address field for unicasting, and then a longer address field,
`again for unicasting, but using a different form of the address that will
`address a specific device.
`By demonstrating that the limitations met under both proposed
`constructions, but as Mr. Batchelder explained, we believe that the
`Petitioner's construction, or the Board's construction, and the institution's
`decision is correct.
`I'll turn here to slide 37, it's the remaining disputed term:
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`16
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`reformatting a message that's set up in Mason, and also in Shuey as we
`discussed a more fulsome disclosure of this as being borrowed. When a
`command or a message comes from the RF node 18, it's sent through
`other meters. For example, meter three acting as a repeater to get to the
`meter N, and when it gets to meter three, it needs to be -- the signal is
`received, that then needs to be updated, and then sent as shown here.
`In the bottom quote, for example, the modified message is
`formatted to your receiver by another meter that's reformatted, and that's
`before it's passed along to meter N. And if there aren’t any further
`questions, in the interest of time, I will reserve any remaining time for
`rebuttal.
`JUDGE MOORE: Okay. I do have one more question, and we are
`going to be a little loose on time, because I believe I was slow on the
`button going forward. But I think we are right around the 10 minutes
`left, that you wanted to reserve. So, the question here is, I believe the
`other side's argument is that the value of the field has changed, but there's
`no formatting to the field itself. Can you speak to that type of argument?
`MR. DAVIS: Yes, Your Honor. And in two ways, the first is the
`specification at the top of column 7 for the 492, talks about formatting,
`and it says, e.g. (inaudible). So, that would be not necessarily altering the
`overall set up of the protocol but altering a field in it. But in addition to
`that, when the message comes from RF node 18, it's in the ASK format,
`it needs to come into meter three, and then be altered to be able to be
`passed along.
`And when it's altered it's not in the ASK format anymore, it needs
`to be altered digitally, and then sent in, the amplitude-shift key format
`
`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
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`again to go to another meter. So, that would reformat the message again
`as it's passed through meter three. So under either interpretation of
`formatting the limitation would be met. Thank you.
`JUDGE MOORE: Patent Owner, whenever you are ready.
`MR. GONSALVES: Your Honor, I'm going to refer to the hard
`copy of the slides, that way all of us would answer, whether or not we are
`in the room, we can be looking at the same thing at the same time. So, I
`will not be using the screen. May I, please, approach the bench to
`handout these slides?
`JUDGE MOORE: Yes.
`JUDGE FITZPATRICK: Again, the hardcopy matches what was
`emailed?
`MR. GONSALVES: Yes, it does, Your Honor.
`JUDGE FITZPATRICK: Perfect. Thank you.
`MR. GONSALVES: May it please the Board? My name is Dr.
`Gregory Gonsalves, and I'll be representing the Patent Owner, SIPCO in
`this (inaudible). Could you, please, turn to slide number 2? Slide
`number 2 lists the grounds, proposed grounds of unpatentability that were
`instituted by the Board, and the ground that was proposed but not
`instituted by the Board.
`If you can please turn to slide 5: slide 5 lists some important
`limitations that we'll be discussing during my presentation today, and that
`will also discuss the Patent Owner's brief. In particular claim 1, for
`example, requires a receiver address to comprise a scalable address of at
`least one remote device, a command indicator comprising of command
`code and a data value comprising a scalable message. The other
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`18
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`independent claims that are challenged in this proceeding recite similar
`limitations.
`And if you can just turn to slide number 7, the Patent Owner's
`construction in this proceeding of a receiver address comprising a
`scalable address of at least one remote device or transceiver is a receiver
`address comprising a scalable address of at least one remote device, and
`requires the address of the remote device, which is within the receiver
`address to be scaled.
`And this claim construction that we are proposing is consistent
`with the Board's ruling in IPR 2015-01579, and IPR 2017-00260.
`
`XXXTRACK 1665XXX
`MR. GONSALVES: The institution's decisions that contained the
`claim construction for this very same claim limitation, was mentioned
`and referred to in our claim construction section of our Patent Owner
`response. And I would, for the Board's convenience, I made the
`institution decision, or the decision denying institution for 01579 and the
`exhibit, and so if you'd like to follow along, and if you can retrieve it on
`your screen, I'll be referring to what's been marked as Exhibit 2006 in
`this proceeding, and in particular from pages 8 and 9. And this is a
`decision written by a Judge Zado, and also with her on the Panel were
`Judges White and Pettigrew.
`And it reads as follows on page 8, "Central to our decision,
`however, is not what scalable means, but rather what is meant by a
`receiver address comprising a scalable address. Claims 1 and 37 recite
`that the receiver address comprises a scalable address of at least one of
`the intended receiving transceiver's remote devices. The language of
`
`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
`
`
`
`19
`
`

`

`Case IPR2016-01895
`Patent 7,697,492 B2
`
`claims 1 and 37, however, does not preclude the receiver address from
`including additional data beyond the address of an intended receiving
`transceiver remote device."
`This is consistent with the 893 specification which, as Judge
`Moore indicated earlier today, is very similar to the specification of the
`patent at issue in this proceeding, of the 492 patents, because the 492
`patent is a continuation of -- the application corresponding to the 492
`patent is a continuation of the application corresponding to the 893
`patent.
`And the specification; both specifications refer to a variable byte
`linked "to" address that comprises both a unique transce

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket