Trials@uspto.gov
`571-272-7822
`
`
`
`
`
` Paper 21
`Entered: August 9, 2022
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SONOS, INC.,
`Petitioner,
`
`v.
`
`GOOGLE LLC,
`Patent Owner.
`____________
`
`IPR2021-00964
`Patent 10,229,586 B2
`____________
`
`Record of Oral Hearing
`Held Virtually: Monday, July 18, 2022
`____________
`
`
`Before KEVIN F. TURNER, TERRENCE W. MCMILLIN, and
`SCOTT RAEVSKY, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`
`
`
` Paper 21
`Entered: August 9, 2022
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SONOS, INC.,
`Petitioner,
`
`v.
`
`GOOGLE LLC,
`Patent Owner.
`____________
`
`IPR2021-00964
`Patent 10,229,586 B2
`____________
`
`Record of Oral Hearing
`Held Virtually: Monday, July 18, 2022
`____________
`
`
`Before KEVIN F. TURNER, TERRENCE W. MCMILLIN, and
`SCOTT RAEVSKY, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`
`
` A
`
` P P E A R A N C E S
`
`
`ON BEHALF OF THE PETITIONER:
`
`
`ALYSSA CARADIS, ESQUIRE
`K. PATRICK HERMAN, ESQUIRE
`ORRICK, HERRINGTON & SUTCLIFFE, LLP
`51 W 52nd Street
`New York, New York 10019
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`KELLY HORN, ESQUIRE
`ERIKA ARNER, ESQUIRE
`DANIEL C. TUCKER, ESQUIRE
`FINNEGAN HENDERSON FARABOW GARRETT & DUNNER
`LLP
`901 New York Avenue, NW
`Washington, D.C. 20001-4413
`
`
`
`
`The above-entitled matter came on for hearing on Monday, July 18,
`2022, commencing at 1:00 p.m. EST, held by video/by telephone.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`2
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`
` (Proceedings begin at 1:00 p.m.)
` JUDGE RAEVSKY: This is Judge Raevsky. Welcome to
`the Patent Trial & Appeal Board.
` We're here today for oral argument in Inter Partes
`Review No. 2021-00964 in which Sonos Inc. is the petitioner
`and Google LLC is a patent owner.
` At issue is U.S. Patent No. 10,229,586 B2.
` Your panel for the hearing today includes myself and
` Judges Turner and McMillin.
` Let's go ahead and get appearances. Who do we have
` for petitioner today?
` MR. HERMAN: Good afternoon, Your Honor. This is
`Patrick Herman from Orrick, Herrington, and Sutcliffe here on
`behalf of petitioner Sonos.
` Also with me on the line is our lead counsel, also
`from Orrick, Alyssa Caradis.
` JUDGE RAEVSKY: Thank you, Mr. Herman.
` MR. HERMAN: I will be giving the presentation
`today.
` JUDGE RAEVSKY: You anticipated my question. Thank
`you.
` And who do we have on behalf of patent owner?
` MS. HORN: Hi. Good afternoon. My name is Kelly
`Horn on behalf of patent owner Google.
` With me today is lead counsel Erika Arner and Dan
`Tucker, backup counsel also for Google.
`3
`
`
`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
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` And in the room today with us we have two of our
` summer associates, Yuchen Han and Laura Brashear, who will
` be listening in.
` And on the public line we also have Patrick Weston,
` senior litigation counsel at Google.
` JUDGE RAEVSKY: Thank you.
` And Ms. Horn, you'll be presenting today?
` MS. HORN: Yes.
` JUDGE RAEVSKY: Thank you, everyone, and welcome,
`including the summer associates. Hopefully this will be a
`good experience for you.
` Before we begin, I have a few reminders.
` First, when you're referring to a slide today,
` please refer to the slide number so that we can follow
` along.
` And also, when you're not speaking, please remember
` to mute yourself.
` And when you do begin to speak, please identify
` yourself for the benefit of the court reporter.
` As has already been noted, members of the public
` will be listening in on this hearing so please keep that in
` mind.
` Each side will have 60 minutes to argue its case
` today. We'll first hear from petitioner and then from
` patent owner.
` Petitioner, Mr. Herman, would you like to reserve
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` any time for rebuttal?
` MR. HERMAN: Yes, Your Honor. 15 minutes, please.
` JUDGE RAEVSKY: Okay. So you'll have 45 minutes for
`your main argument, and when you're ready, you may begin.
` MR. HERMAN: Thank you, Your Honor, and good
`afternoon.
` And I'd like to begin with a brief overview of the
`'586 patent, and that's on Slide 2 of petitioner's
`demonstratives.
` And that slide has Claim 1 on the left and Figure 1
`from the '586 patent on the right.
` And the claim is essentially directed to the
` repeater unit that's shown in the figure. And per the
` claim, the unit must have certain well-known and routinely
`used hardware components, including a wireless transceiver,
`an audio output element, a reset element, and a controller.
` The claim also requires the use of communication
`packets, and it specifies the parts that those packets must
`have; a preamble, an ID code, a data payload, and an
`integrity portion.
` And I would like to briefly pause here and note that
`the '586 patent did not contribute anything new when it
`comes to packets. No new packet structures were proposed or
`disclosed. Instead, it's simply using common, well-known,
`and standardized packet formats that already existed before
`the patent was filed.
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` Now, the final limitations of the patent specify
`what the device must do or be able to do upon receipt of a
`packet. It compares the ID code in the packet to a table,
`and if it finds a match, it determines the relay of the
`packet to another device.
` So in the context of Figure 1, its base unit 112
`sends repeater unit 111, a packet intended for sensor unit
`105. That packet's relayed, because the repeater unit has
`sensor 105 in its table, and knows what to do with packets
`that are directed to sensor 105.
` But packets the sensor 102 would not be relayed by
` that same repeater because the repeater doesn't know where
` to send such a packet.
` So in a nutshell, the claims embrace known repeater
` units with known structures that forward standard wireless
` packets from one place to another.
` JUDGE RAEVSKY: Now, Mr. Herman, I have a question
`about matching an entry in the table of identifiers in the
`claim.
` Is it your position that that requires matching an
` identifier in the table of identifiers or is matching an
` entry broader than that?
` MR. HERMAN: So I believe what must be matched is
`the ID code from the incoming packet.
` So a packet comes into the repeater unit, the
`repeater unit looks up that ID code, compares it to a table,
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`and if it finds a match, it determines to relay the packet on
`to another place. I mean, that's what the claim requires,
`and petitioner submits that's what Baker discloses.
` JUDGE RAEVSKY: Thank you.
` MR. HERMAN: So moving on to Slide 3, this is a
`summary of the grounds.
` So Grounds 1 and 2 start with the Baker reference.
` Ground 3 starts with the Marman reference. So
`there's a handful of disputes across those sets of grounds.
` And I'll go through each of those disputes in turn,
`but I'd like to begin by making a general observation.
` Most of patent owner's arguments simply ignore what
`the prior art says. It fixates on only portions of the art
`while not addressing other disclosures that show that the
`claims are obvious.
` Petitioner submits that the weight of the evidence
`here shows that those claims are, in fact, obvious. In
`fact, much of petitioner's evidence was not even challenged.
` So petitioner submitted two comprehensive expert
`declarations relating to the art's teachings, and patent
`owner declined to take the expert's deposition both times.
` So moving on to Slide 5. Here's an overview of the
`Baker reference that's at issue in the first set of grounds
`in this proceeding.
` And Baker is directed to a network of communication
`devices it calls nodes, and each node includes the same
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`structure and physical components the claims of the '586
`patent require.
` There's also no dispute that Baker employs
` packet-based communications, and that those packets have the
` same parts as the claimed packet.
` And next, as you can see in Figure 3A on the slide,
` some nodes can be out of range of each other, and thus, need
` to have communications relayed through an intermediary. And
` Baker can engage in this packet relaying because each node
` in its network has a stored connection table.
` And I'll talk a bit more about the import of that
` with respect to the claims in a moment.
` So moving on to Slide 6.
` What does Bruckert add? Is shows that reset
` elements existed and were known and had a known impact on
` controller operation, and again, that was common and well
` known in the art.
` JUDGE RAEVSKY: Regarding the reset, I believe you,
`in your petition, had submitted a construction for reset or
`reset element, and patent owner did not appear to dispute
`that in the briefs.
` Do we need to reach that construction at this stage?
` MR. HERMAN: I don't believe that either party has
`argued that that construction gives rise to any disclosure
`issues with respect to the prior art.
` And actually, for the record, I'd like to note that
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`8
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` patent owner raised an issue with respect to the reset
` element in its response brief, petitioner replied, and then
` patent owner didn't provide any further information or
` rebuttal in its sur-reply. So there are arguments and
` explanations that petitioner has made with respect to this
` claim element that are not addressed in this proceeding by
` patent owner.
` So moving on to Slide 7.
` Here's an overview of the parties' Ground 1 dispute.
` And the first dispute relates to whether the prior art makes
` the required determination to relay a packet.
` And you see the second dispute is kind of in the
` lighter gray there, and that relates to that reset element
` that I was just talking about. And again, there are --
` petitioner addressed this in its reply brief, and patent
` owner failed to respond to those reply statements in its
` sur-reply.
` So moving on to Slide 8 and the dispute regarding
` whether the prior art makes a determination to relay that
` the '586 patent claims require.
` And Slide 9. So patent owner starts by arguing that
`Baker purportedly does not make a relay determination
`because, in Baker, at least according to patent owner, a
`packet will always be forwarded if it can be, and this is
`wrong. Baker does not always forward received packets.
`Instead, Baker repeatedly teaches that nodes in this network
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`make packet-forwarding determinations.
` So here on Slide 9, we have a passage from
`paragraph 30 from Baker, and it explains that each network
`node in Baker includes a local routing table. And what's
`the purpose of that table? It allows the individual nodes
`in the network, instead of a central master, to make a
`determination regarding what to do with the received packet.
` And if we move on to Slide 10, this slide includes
`excerpts from paragraphs 84 and 85 of Baker, and these
`paragraphs detail exactly what Baker's nodes do upon receipt
`of a packet and the determinations that the nodes make as
`part of that process.
` So, of course, the node first receives a packet.
`You see that in the green highlighted text from
`paragraph 84.
` Then, as you see in the immediately following yellow
`passage, the node reads a channel number and destination
`address from that packet that it received.
` This then allows the node to determine which of
`three potential courses of action to take. And you see from
`the underlining in that second excerpt, that that is the
`language that Baker itself is using.
` According to Baker, the node is using the channel
`and address information from the incoming packet to
`"determine what to do with the packet."
` Now, again, there's three possible determinations
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`that Baker's nodes can make.
` So first, as you see in the orange text, the node
`can determine that the packet that's been received is
`intended for that node itself. So the recipient node is the
`intended final destination of the packet.
` If the node that received the packets, the final
`destination, the node, of course, does not relay the packet,
`instead, it depacketizes it and sends it along to whatever
`equipment is connected to it. Again, that's the orange
`text.
` So second, if the node is not the intended
`destination, the node can use the channel and address
` information from the incoming packet to perform a look-up
` operation.
` Now, the point of this look-up operation is twofold;
` first, it's intended to determine if the packet can be
` forwarded at all, and second, if the packet can be
` forwarded, it obtains information stored in the table
` regarding the channel that should be used to forward the
` packet.
` Now, if the look-up operation succeeds, the packet
` is retransmitted using the channel that's stored in the
` table. And you see that in the blue text at the bottom of
` the slide.
` And again, you can see that Baker characterized what
` it is doing as a "determination".
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` If Baker's node has used the look-up-and-match
` procedure to determine if a packet can be relayed, and then,
` if so, because a match is found, relays the packet in the
` manner specified in the table for the match.
` JUDGE RAEVSKY: Mr. Herman, this is Judge Raevsky.
` What is the specific piece of information that is
`being matched in the table in Baker?
` MR. HERMAN: The channel and destination address
`from the incoming packet.
` So the node is extracting channel and/or address
`information from an incoming packet and using that
`information to perform a look-up on a stored look-up table.
` JUDGE RAEVSKY: So the channel number in the blue
`highlighted text in the bottom box is the identifier that's
`being matched, in your view.
` MR. HERMAN: Actually, Your Honor, I believe the
`identifier that's being matched is the channel number and/or
`destination address from the second passage that's higher up
`on the slide.
` So what Baker is doing is it is extracting a channel
`number and a destination address from an incoming packet,
`looking up that destination information in a table. If it
`finds the destination information, the table will include
`associated outgoing information for that destination.
` So what's being matched is the destination, and the
` return of the process is an outgoing channel. Right? So
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` that's essentially the secondary information that's found in
` the table once you find the match.
` JUDGE RAEVSKY: Okay.
` MR. HERMAN: Does that answer your question, Your
`Honor?
` JUDGE RAEVSKY: Yes. Thank you.
` I suspect patent owner might respond that nothing in
`this blue text, or anywhere else on the slide, says that
`there's a destination address that's being matched with that
`input address.
` What's your response to that?
` MR. HERMAN: Well, I disagree with that, Your Honor.
`In fact, it says it almost explicitly at the beginning of
`paragraph 85. It says, "Where the node is not the intended
`final destination for the data at step S1302, the incoming
`channel and destination address are used to look up."
` So it's using the incoming channel number and
` destination address to perform a look-up procedure. And the
` output of that look-up procedure is instructions regarding
` how to forward the packet, and that's what Baker says. It
` uses the incoming channel and destination address from the
` incoming packet to look up instructions as to how to forward
` that packet.
` So the match that's being performed is not between
` the input and the output, it's being performed between the
` input and the final destination, and it's receiving
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` instructions as to how to handle that packet as a result of
` the look-up operation.
` JUDGE RAEVSKY: So the destination address is used
`to look up -- or it says "are used to look up an outgoing port
`and channel number."
` So that's in the passive voice so it doesn't tell us
` precisely what it's matched in the table; is that correct?
` So it's your position that it's implied that it's matching
` an address in the table.
` MR. HERMAN: Yes, Your Honor. And I think there are
`portions of Baker that actually go farther than merely being
`an implication.
` So, for instance, if you look at the next slide,
`which is Slide 11, there's Figure 13 from Baker, and
`Figure 13 provides, kind of, a graphical overview of the
`process that's being used to determine how to handle a
`packet.
` And you see that there are three boxes at the bottom
`of the slide. And box S1308 is the process that's followed
`as a result of determining that the node is itself the
`recipient, box S1304 is the process that's followed if the
`node doesn't know where to relay the packet, and S1308, which
`is highlighted in blue, is the result of the performance of
`the determination that's required by the claims here.
` Now, Baker only proceeds to that step if a
` determination has been made to relay the packet.
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` And how is that determination to retransmit made?
` By using channel and address information from an incoming
` packet and performing a look-up operation on a stored
` routing table. And if that look-up operation finds an
` entry, in other words there's a match, then the packet is
` retransmitted, and if it's not, then it's not retransmitted.
` And that's exactly what the figure means when it
` refers to performing a "look-up" and an "entry or device
` being found".
` So what Baker is doing is it's looking for the
` destination device in its look-up table, and if it finds
` that destination device or an entry associated with that
` destination device in its look-up table, then it proceeds
` to perform step 1308. If it doesn't, it performs step 1304.
` So what the look-up procedure is doing, according to
` the figure, is looking for the destination device and
` determining whether it can find an entry associated with
` that destination device in its look-up table.
` Again, taking the channel and address information
`from the incoming packet, comparing it to the look-up table,
`and determining whether that device that's specified in that
`incoming packet, channel or address information's in the
`table so that the node knows how to handle the packet and
`where to send it to.
` That's what Baker is talking about in the
`specification, and that's the procedure it's showing in
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`Figure 13.
` Now, moving on to Slide 12. So as we've seen,
`Baker's network nodes do not always forward packets, they
`only forward packets if they find -- if it finds a matching
`entry in its look-up table.
` Indeed, patent owner itself seems to recognize that
`packets are not always forwarded.
` So the slide here shows what patent owner says about
`Baker in its sur-reply, and it explained that packet
`retransmission is conditioned. So what does that mean? It
`means that even patent owner even recognizes that Baker does
`not always relay packets. Instead, it only relays packets
`in certain conditions. And what are those conditions? As
`we've just seen in Figure 13, a packet is relayed by Baker's
`node only if the node finds a matching entry for the
`incoming packet's channel and/or address in its routing
`table.
` Now, despite this, you see that patent owner argues
`here that the condition used by Baker when determining
`whether to relay is only whether the table stored by the
`node "specifies a valid port and channel number".
` Again, that's just another way of saying that Baker
`has taken identification information from an incoming packet
`and matched it to an entry in its routing table for purposes
`of determining whether the packet can be retransmitted, and
`if so, where it should be sent.
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` The existence of valid port and channel information
`is simply the end result of an overall forward determining
`process that entails using destination information in an
`incoming packet to perform a look-up for purposes of
`determining if a packet can be relayed.
` Now, Slide 13. Baker also repeatedly explains that
`address information can be included in the incoming packet
`for use in this look-up process.
` So paragraph 76 from Baker is on the left of the
`slide, and you see that the address can be used as part of
` the process to query the connection table and "determine an
` outgoing port".
` And again, paragraphs 84 and 85 are reproduced on
` the right, and they repeatedly reference the use of not just
` a channel number from an incoming packet, but also the
` destination address to determine how to handle a packet and
` to perform a look-up operation. So not just comparing
` channels, but comparing address information to information
` stored in a table.
` JUDGE RAEVSKY: So there's a destination address in
`the table, and there's an incoming packet with a destination
`address, and it's your position that one of ordinary skill in
`the art would have understood that Baker here is teaching to
`match those two to decide whether to forward the packet.
` MR. HERMAN: That's right, Your Honor. Yes.
` So remember, again, in Figure 13, Baker contemplates
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
` scenarios where no entry is found in the look-up table. So
` that means that the address can be used to query, and if the
` address is not found, the packet is not relayed. And
` likewise, the determination to relay the packet is made when
` the address is found in that locally stored table.
` Now, this is why Baker teaches what the claims
`require. The determination to relay in Baker is made by
`matching an address from an incoming packet with an entry in
`its look-up table.
` Now, Slide 14. None of the passages cited by patent
`owner say anything to the contrary. Here's one example
`passage from paragraph 31 that patent owner cites in its
`sur-reply.
` And as you'll see, Baker recognizes that there are
`circumstances where a received packet cannot be relayed
`because "recipient is not found in the tables stored by the
`node".
` So the determination of whether forwarding is
`possible that's performed in connection with the look-up and
`then forwarding as specified, if the look-up is successful,
`is, in fact, the claim determining.
` Now, before I move on to Ground 2, I would like to
`briefly address patent owner's apparent attempt to renew its
`arguments regarding the prior art's disclosure of a reset
`element that's operatively coupled to a controller. It made
`this argument in its response, and petitioner replied by
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`explaining why this was wrong.
` Patent owner did not address those reply arguments
`in its sur-reply, but I believe it does have a slide on this
`issue in its demonstratives today.
` And I'd like to briefly list the arguments that
`patent owner did not respond to.
` So the reply pointed out that the discussion of
`reset element in the petition, which is primarily found in
`Section 7(c)(1), then claim limitation 1-3, did more than
`point to the mere presence of reset elements in the system
`of Baker and Bruckert.
` The petition also explained how this reset element
`would be expected to operate and what impact it would have
`on the network node and its controller.
` Now, the reply noted that patent owner ignored this
`latter point, the operation of the reset element.
` Now, the reply also pointed out that patent owner
`failed to rebut the argument in the petition that the
`structure used to power cycle Baker's network node itself
`constitutes a reset element operatively coupled to a
`controller, as claimed.
` Lastly, the reply pointed out that patent owner did
`not address the combined teachings of the art, and
`specifically what Bruckert adds, including Bruckert's
`description of how a reset element affects operation of the
`device controller, so instead, patent owner simply focused
`
`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
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`almost exclusively on what Baker itself discloses.
` Now, moving on to Slide 15 and Ground 2.
` The parties also have a dispute about whether the
`combination of Baker, Bruckert, and McMillin render certain
`dependent claims obvious.
` Slide 16. Here are examples of those dependent
`claims that are at issue. And you can see from this slide
`that the claims are all thematically related. They are
`directed to methods of addressing collisions and congestion
`when communicating over a network.
` Now, there is no dispute that these methods for
`addressing collisions and congestion were known in the prior
`art; the only dispute is whether there would have been
`motivation to apply McMillin's teachings to Baker and
`Bruckert.
` And patent owner's arguments regarding that
`motivation are not technical in nature. It does not appear
`to point to any incompatibility between McMillin and Baker
`or any other technical issues that would be encountered.
`Instead, it appears to only argue that the petition's
`motivation to combine argument is, number 1, purportedly
`limited to just noting that Baker and McMillin are in the
`same general technical field, and number 2, purportedly
`includes only non-specific boilerplate.
` So moving on to Slide 17. That's just wrong, and
`here's what's the petition actually said about 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
`
`20
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`motivation to combine.
` Now, the petition said that McMillin teaches that
`its collision avoidance techniques are particularly useful
`in avoiding issues in networks that include many independent
`transmitters. And the petition goes on to say that because
`all of Baker's nodes can forward packets, Baker's network
`includes many independent transmitters, thus, Baker may be
`subject to the problems that are highlighted by McMillin.
` The petition then goes on to explain that a person
`of ordinary skill in the art would have recognized that
`McMillin's teachings would help address the congestion
`problems present in Baker because it includes many
`independent transmitters.
` So the petition was not just noting that the
`references are in the same general technical field, and it
`was not just providing generic boilerplate. Instead, the
`petition articulated that McMillin is specifically directed
`to solving a potential problem that Baker's network may have
`and includes a solution to that problem.
` And again, patent owner has provided no substantive
`response to any of this.
` So Slide 18. I'm now going to move on to Ground 3,
`and that's the ground that involves Marman and Shoemake.
` Now, Slide 19 provides a brief overview of the
`Marman reference.
` Marman is directed to a wireless fire and security
`
`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
`
`21
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`system with many sensors. And you see several example
`sensors in Figure 1 on the right of the slide.
` Now, each sensor has the claimed controller, a
`wireless transceiver, an audio output element, and a reset
`element. And there's no dispute there.
` And Marman also teaches that its sensors engage in
`packet-based communications. And its sensors can relay
`those packets from one sensor to another allowing for
`indirect communication.
` And it uses routing tables to handle this packet
`relaying, and there's no dispute that the relaying sensors
`make the determination that the '586 patent claims require.
` Now, Slide 20. Here's an overview of Shoemake's
`teachings. And Shoemake teaches a standard packet with a
`preamble, a header, a payload, and a CRC at its end for
`purposes of error correction, and explains that this packet
`is standardized for wireless communication and is a routine
`use.
` Now, Slide 21. Here's an overview of the parties'
`disputes with respect to Ground 3.
` The first two disputes relate to whether the prior
`art teaches a packet with the same parts the claims here
`require, the third dispute relates to Dependent Claim 3, and
`the fourth dispute relates to Dependent Claim 5.
` Now, this fourth dispute is another argument that
`appeared in patent owner's response, and petitioner replied,
`
`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
`
`22
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`but patent owner again did not address those reply arguments
`in its sur-reply.
` And it's got a slide on this issue rehashing its
`response arguments, but again, it has not contested or said
`anything about what petitioner said on the issue in its
`reply brief.
` Now, Slide 22. I'm going to begin with the prior
`art's teaching about the claimed communication packet, but before
`I do so, I'd like to turn to Slide 23 and provide some
`context.
` So this slide includes an excerpt from the Shoemake
`reference. And Figure 3 on the right shows a communication
`packet. And there's no dispute here that this is exactly
`the type of packet the '586 patent's claims require.
` Now, what does Shoemake say about this packet? You
`see from the left, the excerpt on the left, which is
`paragraph 5 from Shoemake, that there are wireless
`networking standards. And under that standard, packets have
`the typical structure shown in Figure 3 of Shoemake. So
`that is the context in which the obviousness analysis here
`is to be performed.
` Obviousness is assessed, including the import of
`Marman's disclosure, as of the '586 patent's filing date.
`And as of that time, it was known that wireless
`communication standards not only existed, but that these
`standards use the same type of packet the '586 patent'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
`
`23
`
`
`
`
`IPR2021-00964
`Patent 10,229,586 B2
`
`claims require.
` And that's all the '586 patent did, it simply used
`the standard packet for wireless c
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
