Paper No. 17
`Filed: June 13, 2022
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`SONOS, INC.,
`Petitioner
`v.
`GOOGLE, LLC,
`
`Patent Owner
`______________________
`
`Case No. IPR2021-00964
`U.S. Patent No. 10,229,586
`
`
`PATENT OWNER’S SUR-REPLY TO PETITIONER’S REPLY
`
`
`
`
`
`
`
`
`Filed: June 13, 2022
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`SONOS, INC.,
`Petitioner
`v.
`GOOGLE, LLC,
`
`Patent Owner
`______________________
`
`Case No. IPR2021-00964
`U.S. Patent No. 10,229,586
`
`
`PATENT OWNER’S SUR-REPLY TO PETITIONER’S REPLY
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`TABLE OF CONTENTS
`Introduction ...................................................................................................... 1
`I.
`II. Grounds 1 and 2: Baker does not determine to relay a packet based on
`an ID code portion in the packet “matching an entry” in Baker’s routing
`table .................................................................................................................. 2
`III. Ground 2: Petitioner has not met its burden of showing a motivation to
`combine McMillin with Baker/Bruckert to reach dependent claims 2-5,
`7, 10-12, 16, 18, and 20 ................................................................................... 6
`IV. Ground 3: Marman does not teach the claimed “communication packet
`including a preamble portion, an identification code portion, a data
`payload portion, and an integrity portion” ...................................................... 8
`A.
`The IEEE 802.11(b) packet was not standardized until after
`Marman’s priority date .......................................................................... 9
`The logical link control and media access control layers are not
`unique to IEEE 802.11(b) .................................................................... 10
`C. Marman does not teach or render obvious a packet with the
`claimed “integrity portion” .................................................................. 13
`V. Ground 3: A POSITA would not have been motivated to modify
`Marman to use Shoemake’s packet structure ................................................ 15
`VI. Ground 3: Petitioner has not shown that Marman “determine[s] a delay
`value,” as recited by dependent claim 3 ........................................................ 18
`VII. Conclusion ..................................................................................................... 20
`
`
`B.
`
`
`
`
`
`i
`
`
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Baran v. Med. Device Techs., Inc.,
`616 F.3d 1309 (Fed. Cir. 2010) .......................................................................... 19
`Belden Inc. v. Berk-Tek LLC,
`805 F.3d 1064 (Fed. Cir. 2015) .......................................................................... 14
`Comcast Cable Commc’ns, LLC v. Promptu Sys. Corp.,
`838 F. App’x 555 (Fed. Cir. 2021), cert. denied, 141 S. Ct. 2721
`(2021) .................................................................................................................... 6
`Comcast Cable Commc’ns, LLC v. Promptu Sys. Corp.,
`IPR2018-00340, Paper 58 (PTAB Mar. 29, 2019) ........................................... 6, 7
`In re Fine,
`837 F.2d 1071 (Fed. Cir. 1988) ............................................................................ 6
`In re Fritch,
`972 F.2d 1260 (Fed. Cir. 1992) ............................................................................ 6
`Graham v. John Deere Co. of Kansas City,
`383 U.S. 1 (1966) .................................................................................................. 8
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ...................................................................................... 15, 19
`In re Nuvasive,
`842 F.3d at 1384-85 ............................................................................................ 15
`Palo Alto Networks, Inc. v. Finjan, Inc.,
`777 F. App’x 501 (Fed. Cir. 2019) ..................................................................... 14
`Pers. Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) .............................................................................. 8
`Tec Air, Inc. v. Denso Mfg. Mich. Inc.,
`192 F.3d 1353 (Fed. Cir. 1999) .................................................................... 16, 18
`
`ii
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`
`TIP Sys., LLC v. Phillips & Brooks/Gladwin, Inc.,
`529 F.3d 1364 (Fed. Cir. 2008) .......................................................................... 19
`
`
`
`
`
`
`
`
`iii
`
`
`
`
`I.
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`Introduction
`Petitioner’s Reply overlooks the ’586 patent’s inventive features by
`
`oversimplifying the claims and ignoring their inventive combinations. Taken as a
`
`whole, the ’586 patent’s claims require selectively relaying messages having a
`
`particular packet structure to nodes listed in an intermediary device’s “table of
`
`identifiers.” See Ex. 1001 at 17:22-46. Petitioner has not met its burden of showing
`
`that this inventive feature of the claims would have been obvious.
`
`Petitioner’s Baker-based Grounds 1 and 2 are flawed because Baker
`
`conditions its packet retransmission determination on something entirely different
`
`than the conditions required in the independent claims. While the claimed controller
`
`“determine[s] to relay the communication packet” based on “the identification code
`
`portion of the received communication packet matching an entry in the table of
`
`identifiers” (Ex. 1001, 17:29-44), Baker bases its retransmission on the mere
`
`existence of valid routing information in a local routing table (Ex. 1004, ¶ [0085]).
`
`Petitioner’s Ground 2 fails for another, independent, reason: Petitioner has not
`
`demonstrated how
`
`its omnibus motivation
`
`to combine McMillin with
`
`Baker/Bruckert aligns with the specific dependent claim recitations challenged in
`
`Ground 2. Petitioner has thus failed to meet its legal burden of showing that the
`
`dependent claims challenged in that ground would have been obvious.
`
`1
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`Regarding Ground 3, Petitioner’s new evidence introduced in its Reply fails
`
`
`
`to cure the deficiencies of its Petition. Specifically, it does not show that Marman
`
`alone, or in combination with Shoemake, renders obvious all the features of the
`
`independent claims. While Petitioner argues that Marman is “invoking and
`
`referencing a standard IEEE 802 packet” (Ex. 1028, ¶ 50), the particular IEEE
`
`802.11(b) packet Petitioner alleges to be implicitly referenced was not standardized
`
`until after Marman’s filing date. Marman contains no explicit or implicit reference
`
`to this packet, despite Petitioner’s attempt to use Marman’s more generalized
`
`disclosures to manufacture one. Finally, Petitioner has failed to articulate a reason—
`
`other than hindsight—why a POSITA would have been motivated to select the IEEE
`
`802.11(b) packet from all the other available standardized alternatives available at
`
`the time for use in Marman’s system.
`
`II. Grounds 1 and 2: Baker does not determine to relay a packet based on
`an ID code portion in the packet “matching an entry” in Baker’s
`routing table
`Claim 1 requires that the controller, “based on the comparison of the
`
`identification code portion of the received communication packet matching an
`
`entry in the table of identifiers . . . , determine[s] to relay the communication
`
`packet to another audio-enabled wireless device.” Ex. 1001 at 17:29-44 (emphases
`
`added). Independent claims 9 and 15 recite similar features in the context of method
`
`and system claims. Id. at 18:25-33, 19:1-9. Each of the independent claims thus
`
`2
`
`
`
`
`conditions the determination to relay a packet on a specific basis—a match
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`between an ID code portion of the incoming packet and an entry in the table of
`
`identifiers. Id. at 17:29-44, 18:25-33, 19:1-9. This is because in embodiments of the
`
`’586 patent, a repeater “only communicates with designated wireless sensor units
`
`whose IDs appear[] in the repeater’s database” or table. Ex. 1001 at 3:19-21. By
`
`checking to make sure the ID code portion in the incoming packet matches an entry
`
`in its table of identifiers before deciding to relay it, the repeater ensures that it
`
`forwards packets for only the devices it is intended to service. These claimed features
`
`are not disclosed by any of the Baker embodiments.
`
`Petitioner focuses in its Reply on the operation of the “store and forward
`
`node” of Figure 13 in Baker. See Reply at 4-6 (discussing Ex. 1004, ¶¶ [0084],
`
`[0085]). But this node type in Baker is not dedicated to servicing only certain
`
`destinations and thus serves a different purpose than the ’586 patent’s controller.
`
`See, e.g., Ex. 1004, ¶¶ 27-29 (explaining how intermediary devices are only “locally
`
`aware” such that “data is forwarded through the network until reaching its intended
`
`recipient.”). Rather, it is dedicated to finding the appropriate channel upon which to
`
`forward all the incoming data it can. Id. As such, Baker’s store-and-forward nodes
`
`have no reason to condition a packet relay determination on a match between
`
`address information in a packet and an entry in the node’s routing table, as claimed
`
`by the ’586 patent.
`
`3
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`Faced with this fundamental difference between Baker and the ’586 patent,
`
`
`
`Petitioner contorts Baker’s operation in an attempt to fit it into the contours of the
`
`claims, stating that Baker’s nodes forward packets “only if they can.” See Reply at
`
`4. Specifically, without a single citation to Baker, Petitioner alleges that Baker’s
`
`“nodes are only able to forward a packet if the channel/address information in the
`
`incoming packet matches an entry in the lookup table.” Id. But even this does not
`
`meet the language of the claims. The claims do not require that the node is merely
`
`able to forward the packet if there is a match; they require that the node’s controller
`
`makes an affirmative determination to do so based on a match. And Baker’s nodes
`
`do not make a determination to relay on this claimed basis.
`
`Petitioner attempts to manufacture such a determination from the mere fact
`
`that in some embodiments a comparison occurs between a MAC address in the
`
`packet and a destination address in the routing table. Id. at 5-6. But the claim requires
`
`more than just this comparison; it requires both a match and that the determination
`
`to relay is based on that match. While Petitioner alleges that this determination
`
`occurs in step S1308 of Baker’s Figure 13, Petitioner’s conclusion that “[i]f a match
`
`is found in the table, the packet is relayed” is not supported by Baker’s disclosure.
`
`See id. at 6.
`
`Instead, in Baker, the packet retransmission at step S1308 is conditioned on a
`
`different basis—“[w]here the table entry specifies a valid port and channel number.”
`
`4
`
`
`
`
`Ex. 1004, ¶ [0085]. Put simply, in Baker, it is not a “match” that triggers the
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`retransmission; it is the existence of valid routing information in the routing table.
`
`Indeed, Baker discloses that a “match” with the table can occur, but with presently
`
`invalid port and/or channel number information such that no retransmission occurs.
`
`See, e.g., Ex. 1004, ¶ [0031]. This is because in Baker, it is the existence of valid
`
`routing information in the table that forms the basis for packet retransmission, not a
`
`match between an ID code portion and a table identifier. This is true even of the
`
`paired MAC address embodiment that Petitioner focuses on in its Reply. See Reply
`
`at 4. In Baker’s “example routing table structure using paired MAC . . . addresses”
`
`in FIG. 11d, channel information still exists in addition to the addresses to enable
`
`the intermediary device #2 to forward data. Ex. 1004, ¶ [0082]; Figure 11d. Again,
`
`it is not the presence of the MAC address itself in the routing table that forms the
`
`basis for a determination to relay; rather, it is the presence of valid routing
`
`information.
`
`Basing retransmission on the existence of valid routing information (i.e., a
`
`port and channel number) in the routing table, as taught in Baker, is not the same as
`
`“determin[ing] to relay” the packet “based on the comparison of the identification
`
`code portion … matching an entry in the table of identifiers,” as claimed. See Ex.
`
`1001 at 17:36-44. And Petitioner’s theory that merely “comparing identifying data
`
`in an incoming packet to data stored in a lookup table” necessarily means that the
`
`5
`
`
`
`
`retransmission is based on the claimed “match” boils down to no more than
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`impermissible hindsight reconstruction. See In re Fritch, 972 F.2d 1260, 1266 (Fed.
`
`Cir. 1992) (“It is impermissible to use the claimed invention as an instruction manual
`
`or ‘template’ to piece together the teachings of the prior art so that the claimed
`
`invention is rendered obvious.”); In re Fine, 837 F.2d 1071, 1075 (Fed. Cir. 1988)
`
`(“One cannot use hindsight reconstruction to pick and choose among isolated
`
`disclosures in the prior art to deprecate the claimed invention.”). As such, Petitioner
`
`has failed to meet its burden to prove that the claims challenged in Grounds 1 and 2
`
`are unpatentable.
`
`III. Ground 2: Petitioner has not met its burden of showing a motivation to
`combine McMillin with Baker/Bruckert to reach dependent claims 2-5,
`7, 10-12, 16, 18, and 20
`Petitioner’s omnibus motivation to combine McMillin with Baker/Bruckert,
`
`unpaired to any particular claim limitation, is legally deficient because it falls short
`
`of meeting Petitioner’s evidentiary burden of proving obviousness of each of the
`
`claimed features. See Pet. 56-58; see also Comcast Cable Commc’ns, LLC v.
`
`Promptu Sys. Corp., IPR2018-00340, Paper 58 at 26 (PTAB Mar. 29, 2019) (finding
`
`Petitioner’s rationale for its combinations insufficient because it was “untethered to
`
`any claim element, or to the claim as a whole”); Comcast Cable Commc’ns, LLC v.
`
`Promptu Sys. Corp., 838 F. App’x 555, 557 (Fed. Cir. 2021) (upholding Board
`
`finding of lack of “motivation to combine because [the petition] merely (1) alleged
`
`6
`
`
`
`
`the references came from the same field of study and address the same problem; and
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`(2) recited boilerplate legal conclusions untethered to any claim language”), cert.
`
`denied, 141 S. Ct. 2721 (2021). In its Reply, Petitioner doubles down on this legally
`
`inadequate analysis, declaring that the dependent claims are “thematically similar”
`
`and the omnibus “motivation to combine . . . is directly tied to the techniques for
`
`avoiding network issues taught by” McMillin. Reply at 9. But the Board has
`
`previously rejected the sufficiency of pointing to the fact that references “are within
`
`the same field and are directed to solving the same problem” when articulating the
`
`requisite motivation to combine. See Comcast, IPR2018-00340, Paper 58 at 26.
`
`Petitioner then posits that its omnibus motivation to combine is a sufficient
`
`“brief explanation,” which is all the law requires because “the ’586 patent claims
`
`well-known, and routinely used techniques for improving network communication.”
`
`Reply at 10 (citing Pers. Web Techs., LLC v. Apple, Inc., 848 F.3d 987, 994 (Fed.
`
`Cir. 2017)). But Petitioner did not provide even a brief explanation of why a POSITA
`
`would have found it obvious to combine the particular claim limitations in each
`
`of the dependent claims that Petitioner alleges to be in McMillin with
`
`Baker/Bruckert. Moreover, the “brief explanation” referred to in Personal Web
`
`referred to the amount of explanation the Board must provide in its decisions “to
`
`enable judicial review and to avoid judicial displacement of agency authority,” not
`
`7
`
`
`
`
`the standard a Petitioner must meet to show the requisite motivation to combine.
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`Pers. Web, 848 F.3d at 994.
`
`IV. Ground 3: Marman does not teach the claimed “communication packet
`including a preamble portion, an identification code portion, a data
`payload portion, and an integrity portion”
`Because Marman fails to explicitly reference the IEEE 802.11(b) packet,
`
`Petitioner’s allegation that “Marman actually teaches” it is premised on the notion
`
`that a POSITA would have nevertheless understood Marman to be implicitly
`
`suggesting it. See Reply at 15; Ex. 1028, ¶ 50. But Petitioner’s method of finding
`
`reference to this particular packet in Marman is pure hindsight reconstruction.
`
`Petitioner’s expert uses the ’586 patent’s packet structure as a guide through
`
`Marman’s disclosures, combining its pieces in the “right” way to work backwards
`
`to reach the IEEE 802.11(b) packet. See, e.g., Ex. 1028, ¶¶ 47-50. Not only is this
`
`legally incorrect, but the methodology also results in a fundamentally flawed result,
`
`as Petitioner’s evidence fails to conclusively establish that Marman could have been
`
`referencing only the IEEE 802.11(b) packet. See Graham v. John Deere Co. of
`
`Kansas City, 383 U.S. 1, 36 (1966) (failing to “resist the temptation to read into the
`
`prior art the teachings of the invention in issue” is improper).
`
`Specifically, Petitioner’s conclusion that “a POSITA would in fact consider
`
`Marman to be invoking and referencing a standard IEEE 802 packet” is premised on
`
`(1) “Marman’s reference to [] packet parts like those employed by standard IEEE
`
`8
`
`
`
`
`packets” and (2) “its reference to the use of the LLC and MAC layers that are part
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`of the IEEE standard.” Ex. 1028, ¶ 50. Yet none of Petitioner’s evidence shows that
`
`these disclosures in Marman, taken alone or in combination, would implicitly
`
`convey to a POSITA that the IEEE 802.11(b) packet was necessarily used in
`
`Marman. And without reliance on this standardized packet structure, Petitioner
`
`cannot show that Marman discloses a single data structure with all the recited
`
`components, as required by each of the ’586 patent’s independent claims.
`
`A. The IEEE 802.11(b) packet was not standardized until after
`Marman’s priority date
`Petitioner faults Patent Owner for “approach[ing] Marman as if the 802 family
`
`of standards did not exist, and the standard protocols discussed in Marman are not
`
`standard but are somehow unique and idiosyncratic to Marman.” Reply at 17. But
`
`Petitioner is not relying on the entire “802 family of standards,” it is relying on one
`
`amendment to a particular IEEE 802 family member—IEEE 802.11(b).1. See Pet. at
`
`
`1 IEEE 802 is a collection of standards, with the numeral after the period indicating
`
`the application (e.g., Ethernet, Wireless LAN, etc.), and the letter denoting an
`
`amendment
`
`to
`
`that
`
`application’s
`
`standard.
`
`See,
`
`e.g.,
`
`https://standards.ieee.org/featured/ieee-802/;
`
`https://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm.
`
`9
`
`
`
`
`62 (referring to the IEEE 802.11(b) packet, as shown in Shoemake); Ex. 1010, ¶
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`[0005], [0008]; Ex. 1019, p. 6 (“This standard is a revision of IEEE Std 802.11-
`
`1997.”); Ex. 1020, p. 4 (“This standard is a revision of IEEE Std 802.11-1997.”).
`
`And Petitioner’s own evidence shows that this version of the standard was published
`
`in August of 1999—almost a year after Marman’s October 6, 1998 filing date. Ex.
`
`1019, p. 3; Ex. 1020, p. 2; Ex. 1006, p. 1.
`
`It belies logic to suggest that a POSITA would have understood that Marman
`
`was “invoking and referencing a standard IEEE 802 packet like that exemplified by
`
`Shoemake” that was not yet in existence when Marman was written. See Ex. 1028,
`
`¶ 50. The fact that the IEEE 802.11(b) packet became standardized after Marman’s
`
`priority date strongly suggests that Marman was not implicitly referencing it.
`
`B.
`
`The logical link control and media access control layers are not
`unique to IEEE 802.11(b)
`Petitioner next posits that “[t]he ‘media access layer and logical link layer
`
`protocols’ referenced in Marman would be understood to be part of the IEEE 802
`
`standardized network communication architecture.” Reply at 12. This leap from
`
`Marman’s scant disclosure to the invocation of the entire IEEE 802 family of
`
`standards, however, is irreconcilable with Petitioner’s own evidence. Moreover,
`
`even if it were true that Marman suggests the IEEE 802 family to a POSITA, this is
`
`10
`
`
`
`
`irrelevant to the critical question of whether Marman implicitly teaches the packet
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`in just one specific amendment to one particular family member—IEEE 802.11(b).
`
`Petitioner first implies that the “protocols” Marman is referencing must be
`
`IEEE 802.2 and IEEE 802.11 based on selectively excerpted titles from a summary
`
`page in the 1999 version of the IEEE 802.11 standard. Reply at 12. But Petitioner
`
`never even alleges that any packet structure in IEEE 802.2 satisfies the claim
`
`language, rendering this specific family member irrelevant to Marman’s alleged
`
`teaching of the claimed packet structure. And while the term “medium access”
`
`appears in the IEEE 802.11 title, one cannot conclude that a POSITA would have
`
`understood IEEE 802.11 to be referenced by this commonality alone. The term
`
`“medium access” in the IEEE 802.11 title is used in the context of just one
`
`application: “Wireless LAN Medium Access Control (MAC) and Physical Layer
`
`Specifications.” Ex. 1019, p. 6. This term also appears in the listed titles for IEEE
`
`802.1D (“Media Access Control (MAC) Bridges”), 802.1G (“Remote Media Access
`
`Control (MAC) Bridging”), and 802.9 (“Integrated Services (IS) LAN Interface at
`
`the Medium Access Control (MAC) and Physical (PHY) Layers”). Ex. 1019, pp. 5-
`
`6. Petitioner never explains why a POSITA would understand Marman’s reference
`
`to a “media access layer” protocol to necessarily be to IEEE 802.11(b), especially
`
`when several other family members also relate to the media access layer.
`
`11
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`Petitioner next attempts to use the fact that “[t]he MAC and LLC layers
`
`
`
`discussed in Marman are . . . part of the [IEEE 802.11] standard” as a magnet to
`
`draw the IEEE 802.11(b) packet into Marman where it otherwise would not be.
`
`Reply at 13; see also id. at 18 (“Marman’s system already employs network protocol
`
`layers present in the IEEE 802 standard, including the MAC and LLC sublayers.”).
`
`But again, the presence of the MAC and LLC layers in the IEEE 802 reference model
`
`does not conclusively establish an implicit reference to that model in Marman—
`
`particularly where the evidence of record clearly shows these layers to be features
`
`of other models too.
`
`Petitioner also tries to artificially link Marman’s general disclosure of the
`
`MAC and LLC layers to the IEEE 802.11(b) standard. Reply at 13-14. To support
`
`this argument, Petitioner relies heavily on Tam to assert that these layers are
`
`“repeatedly discussed in the patent literature,” which “depicts this layered
`
`architecture in the same way as the IEEE 802 standard itself.” Reply at 13-14. But
`
`as Dr. Madisetti explained during his deposition, the architecture described in Tam
`
`is not based on the Open Systems Interconnection (“OSI”) model that Petitioner
`
`alleges is the basis of the IEEE 802 family. Ex. 1027 at 32:4-34:18. Instead, Tam
`
`discusses a different architecture that also includes MAC and LLC layers. Ex. 1025
`
`at 2:6-8 (“Examples of such communications architectures include the Systems
`
`Network Architecture (SNA) developed by International Business Machines
`
`12
`
`
`
`
`Corporation and the Internet communications architecture.”); 2:37-40 (“The data
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`link layer . . . may be further divided into two sublayers: Logical Link Control (LLC
`
`122) and Media Access Control (MAC 124).”); Ex. 1027 at 34:13-18 (“I don’t see
`
`that disclosure. It’s specifically talking about SNA from IBM. It doesn’t refer to
`
`OSI.”). As such, Petitioner’s evidence shows that Marman’s reference to “media
`
`access layer and logical link layer protocols” alone cannot constitute a specific
`
`reference to the IEEE 802.11 standard merely by mentioning layers that happen to
`
`also be in that standard’s reference model. This faulty conclusion can be reached
`
`only by cherry picking a standard with the claimed packet components and working
`
`backwards to link that standard to Marman’s disclosure—which is not proper.
`
`C. Marman does not teach or render obvious a packet with the
`claimed “integrity portion”
`Petitioner alleges that the “packet error control” disclosed in Marman (Ex.
`
`1006, 38:9-12) is performed by the “media access layer and logical link layer
`
`protocols” mentioned elsewhere in Marman, and, as such, this “packet error control”
`
`must be referring to a portion (i.e., the FCS) of the packet in the IEEE 802.11(b)
`
`standard. Reply at 20. But as explained above, the 1999 version of the IEEE 802.11
`
`standard that Petitioner alleges is implicitly being referred to in Marman did not
`
`exist when Marman was written. See supra Section IV(A); see also Reply at 20
`
`13
`
`
`
`
`(citing Ex. 1019). It is thus nonsensical to suggest that Marman intended to refer to
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`a standard not yet in existence when referring to “packet error control.”
`
`Further, Petitioner relies on the fact that in the “IEEE 802 standard, the media
`
`access control layer employs a” CRC. Reply at 20. But Marman is clear that it is the
`
`“logical link control”—not the media access layer control—that “includes . . . packet
`
`error control.” Ex. 1006, 38:9-12. Petitioner has not even attempted to explain why
`
`a POSITA would look to something that the “media access control layer employs”
`
`to understand what the “packet error control” is in view of this disclosure in Marman.
`
`In short, Petitioner’s theory of how Marman allegedly teaches the recited
`
`“integrity portion” is premised on the incorrect assumption that a POSITA reading
`
`Marman would understand Marman to be teaching the later-standardized IEEE
`
`802.11(b) packet. But Marman’s actual disclosures do not go so far. Marman merely
`
`discloses “packet error control,” which is not an “integrity portion,” as the term is
`
`used in the context of the ’586 patent. Ex. 2006, ¶ 73; see also Ex. 1001 at 11:5-6
`
`(providing a checksum as an example of an “integrity portion”). Integrity portions,
`
`like a checksum, verify the integrity of the data transmitted in the packet, a feature
`
`that “packet error control” does not necessarily include. Ex. 2006, ¶¶ 73, 75. The
`
`mere fact that a checksum “could be” one of the forms that packet error control takes,
`
`as alleged by Dr. Wicker, is not enough to show an affirmative teaching in Marman
`
`of the claimed “integrity portion.” See Ex. 1003, ¶ 441; Ex. 2006, ¶ 75; see also
`
`14
`
`
`
`
`Belden Inc. v. Berk-Tek LLC, 805 F.3d 1064, 1073 (Fed. Cir. 2015) (“[O]bviousness
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`concerns whether a skilled artisan not only could have made but would have been
`
`motivated to make the combinations or modifications of prior art to arrive at the
`
`claimed invention.”); Palo Alto Networks, Inc. v. Finjan, Inc., 777 F. App’x 501,
`
`506 (Fed. Cir. 2019) (affirming the Board’s finding that an element that might serve
`
`a particular function did not teach or suggest the claim term); KSR Int’l Co. v.
`
`Teleflex Inc., 550 U.S. 398, 418 (2007) (“[I]t can be important to identify a reason
`
`that would have prompted a person of ordinary skill in the relevant field to combine
`
`the elements in the way the claimed new invention does.”);
`
`V. Ground 3: A POSITA would not have been motivated to modify
`Marman to use Shoemake’s packet structure
`Petitioner was required to “articulate a reason why the [POSITA] would have
`
`been motivated to modify” Marman to incorporate Shoemake’s packet. See In re
`
`Nuvasive, 842 F.3d at 1384-85 (reversing finding of obviousness because “the PTAB
`
`failed to articulate a reason why the [POSITA] would have been motivated to
`
`modify” a base reference to include additional information taught by a secondary
`
`reference); see also KSR, 550 U.S. at 418 (“[I]t can be important to identify a reason
`
`that would have prompted a person of ordinary skill in the relevant field to combine
`
`the elements in the way the claimed new invention does.”). The only “reason”
`
`Petitioner provided is that a POSITA would have considered it obvious to use such
`
`15
`
`
`
`
`a packet because it was ‘standard’ and ‘typical’ when the ’586 patent was filed.” Pet.
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`63-64. Petitioner now takes issue with Dr. Madisetti’s explanation that a variety of
`
`other suitable, standardized protocols also existed and were available for a POSITA
`
`to select, seemingly requiring that Dr. Madisetti explain why a POSITA would select
`
`one of those protocols. Reply at 21-22; see also Ex. 2006, ¶ 78. But again, it is
`
`Petitioner’s burden to show the inverse: why a POSITA would select the IEEE
`
`802.11(b) packet from a wide variety of packets taught by the numerous standards
`
`available to a POSITA at the time of invention of the ’586 patent. Petitioner failed
`
`to meet that burden.
`
`Moreover, Patent Owner has shown that Marman teaches away from using a
`
`packet with Shoemake’s complexity, rendering the combination improper. See
`
`Response at 30-33; Ex. 2006, ¶¶ 78-82; see also Tec Air, Inc. v. Denso Mfg. Mich.
`
`Inc., 192 F.3d 1353, 1360 (Fed. Cir. 1999) (finding an obviousness combination
`
`improper “if a reference teaches away from its combination with another source.”).
`
`Petitioner nevertheless argues that there is no teaching away because “Marman (1)
`
`already teaches the use of packet-based communication, (2) already employs the
`
`IEEE 802 network protocol standard, and (3) already expressly references and uses
`
`many of the parts of an 802.11 packet.” Reply at 22-23. Each of these reasons is
`
`flawed.
`
`16
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`First, the fact that Marman contemplates packet-based communication does
`
`
`
`not mean that Marman embraces use of all types of packets. Marman can (and does)
`
`still teach away from the use of certain types of packets. In particular, Marman is
`
`specifically concerned with conserving battery power and reducing costs through
`
`“enhancements [that] include battery conserving communications protocols.” Ex.
`
`1006, 3:13-14, 4:10-13; Ex. 2006, ¶ 79. Marman thus contemplates that certain
`
`“communications protocols,” including the packets defined by those protocols, are
`
`consistent with its goals, while others are not.
`
`Second, Petitioner’s assertion that Marman “already employs the IEEE 802
`
`network protocol standard” is simply wrong. See Reply at 22-23. First, Petitioner
`
`has not presented any evidence that there is one, single “IEEE 802 network protocol
`
`standard.” Indeed, there is an “IEEE 802 family of standards [that] consists of 71
`
`published
`
`standards,” with
`
`additional ones under development. See
`
`https://standards.ieee.org/featured/ieee-802/. And Petitioner’s suggestion
`
`that
`
`Marman somehow employs this entire family of standards without mentioning a
`
`single one of them is evidentiarily unsupported. Moreover, while Petitioner alleges
`
`elsewhere that Marman implicitly references one of those standards, IEEE
`
`802.11(b), that version of the standard did not exist as of Marman’s priority date,
`
`such that Marman cannot reasonably be said to be “already employ[ing]” it. See
`
`supra Section IV(A).
`
`17
`
`
`
`Patent Owner’s Sur-Reply – IPR2021-00964
`U.S. Patent No. 10,229,586
`
`Third, Petitioner’s assertion that Marman “expressly references and uses
`
`
`
`
`many of the parts of an 802.11 packet” (Reply at 23), is not germane to whether a
`
`POSITA would have been motivated to put all those parts together into a single data
`
`structure for transmission. See Ex. 2006, ¶¶ 59-61 (explaining that a communication
`
`packet is a “single
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
