UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`SONOS, INC.,
`Petitioner,
`v.
`GOOGLE LLC,
`Patent Owner.
`
`____________________________
`
`U.S. Patent No. 10,229,586
`Case No. IPR2021-00964
`_________________________________________________________________
`
`SONOS, INC.’S REPLY
`_________________________________________________________________
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`SONOS, INC.,
`Petitioner,
`v.
`GOOGLE LLC,
`Patent Owner.
`
`____________________________
`
`U.S. Patent No. 10,229,586
`Case No. IPR2021-00964
`_________________________________________________________________
`
`SONOS, INC.’S REPLY
`_________________________________________________________________
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`Ground 1: The Petition Established that Baker and Bruckert
`Render the ’586 Patent’s Claims Obvious ....................................................... 2
`Baker Teaches “Determining to Relay the Packet Based on a
`Comparison of the Identifiers” ................................................................... 2
`Baker and Bruckert Teach a “Controller Operatively Coupled
`to … Reset Element” .................................................................................... 7
`Ground 2: There Would Have Been a Strong and Straightforward
`Motivation to Combine McMillian with Baker and Bruckert .......................... 9
`III. Ground 3: The Petition Also Established that Marman and
`Shoemake Render the Claims Obvious .......................................................... 10
`A POSITA Would Have Understood Marman Itself Teaches the
`Claimed Packets .......................................................................................... 11
`Marman and Shoemake Teach Packets with the Claimed
`“Integrity Portion” ....................................................................................... 19
`It Also Would Have Been Obvious to Apply Shoemake’s
`Teachings to Marman ................................................................................. 21
`Marman and Shoemake Render Claim 3 Obvious ................................ 24
`Marman and Shoemake Render Claim 5 Obvious ................................ 25
`
`-i-
`
`
`
`LISTING OF EXHIBITS
`
`Exhibit
`
`Description
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`
`U.S. Patent No. 10,229,586 to Kates
`
`File History of U.S. Patent No. 10,229,586 to Kates
`
`Declaration of Dr. Stephen B. Wicker
`
`U.S. Publication No. 2006/0120433 A1 to Baker et al.
`
`U.S. Provisional App. No. 60/518,327
`
`WO 00/21053A1 to Marman et al.
`
`Case Management and Pretrial Order for Claims Construction from
`Google LLC, v. Sonos, Inc., Case No. 20-cv-03845-EMC (N.D.
`Cal.)
`
`Time to Trial Statistics for the U.S. District Court for the Northern
`District of California from 2008-Present
`
`EP 0 416 732 B1 to Bruckert et al.
`
`U.S. Publication No. 2002/0122413 A1 to Shoemake
`
`File History of U.S. App. 15/601,705
`
`File History of U.S. App. 15/090,973
`
`Excerpt from the Authoritative Dictionary of IEEE Standards
`Terms, Seventh Edition (2000)
`
`Redline comparison of the specifications of U.S. Publication No.
`2006/0120433 A1 to Baker et al. and U.S. Provisional App. No.
`60/518,327.
`
`U.S. Patent No. 4,585,906 to Matthews et al.
`
`U.S. Patent No. 6,493,824 to Novoa et al.
`
`-ii-
`
`
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`1026
`
`1027
`
`1028
`
`U.S. Patent No. 6,496,858 to Frailong et al.
`
`U.S. Patent No. 7,027,773 to McMillin
`
`IEEE 802.11 Specification (1999 Edition)
`
`IEEE 802.11a Specification (1999 Edition, R2003)
`
`Akyildiz et. al., “Wireless Mesh Networks: A Survey,” Computer
`Networks (2004)
`
`Beckman et al., “Use of mobile mesh networks for inter-vehicular
`communication,” 2003 IEEE 58th Vehicular Technology
`Conference (VTC 2003-Fall)
`IEEE Standards for Local and Metropolitan Area Networks:
`Overview and Architecture, Std 802-1990 (Dec. 31, 1990).
`IEEE Standard for Information Technology, Part 2: Logical Link
`Control, ANSI/IEEE Std. 802.2 (1998)
`
`U.S. Patent No. 6,115,751 to Tam et al.
`
`U.S. Patent No. 4,941,089 to Fischer
`
`Transcript from the April 20, 2022 Deposition of Dr. Vijay K.
`Madisetti
`
`Reply Declaration of Dr. Stephen B. Wicker
`
`-iii-
`
`
`
`Petitioner Sonos, Inc. submits this reply to Patent Owner Google LLC’s
`
`response (Paper 11, “Response”)
`
`Patent Owner’s response repeatedly and egregiously ignores what the prior art
`
`of record teaches. Rather than considering what the art says, and what the Petition
`
`argued, it focuses only on select, isolated passages in an effort to save the facially
`
`unpatentable claims of the ’586 patent.
`
`For instance, Patent Owner argues that Baker does not teach “determining” to
`
`relay a received packet based on a comparison between an address in the packet and
`
`a stored address. In Patent Owner’s view, Baker’s network nodes supposedly
`
`“always” forward received packets. Baker’s nodes do not always forward packets.
`
`The nodes only forwards packets if there is a match between the packet’s address
`
`and that stored in the node’s routing table. If there is no match, the packet is not
`
`forwarded. This is the claimed “determining.” And, Patent Owner simply ignores
`
`this functionality.
`
`Likewise, Patent Owner’s attempts to distinguish Marman ignore what the
`
`reference actually says. According to Patent Owner, Marman would not be
`
`understood to employ the claimed “communication packet.” Patent Owner
`
`characterizes Marman as teaching only the transmission of “disparate,” unrelated
`
`pieces of information and not a single packet that includes all the parts required.
`
`But, in arriving at this conclusion, Patent Owner ignores both Marman’s disclosure,
`
`-1-
`
`
`
`as well as how a POSITA’s background knowledge would inform the understanding
`
`of Marman. In particular, Marman expressly states that it employs packets,
`
`references and discusses the use of all the claimed packet parts, and even states that
`
`it employs the same layered network protocol as the IEEE 802 standard (which
`
`operates on a single packet that includes all the claimed parts). When read in context,
`
`it is apparent that Marman either already uses—or could be obviously modified to
`
`employ—a standard IEEE 802 packet.
`
`Patent Owner also briefly addresses Baker and Bruckert’s “reset element,” the
`
`motivation to apply McMillian’s teachings in Ground 2, Marman’s teaching of an
`
`“integrity portion,” and Marman’s disclosure of certain dependent claim limitations.
`
`But here, Patent Owner either limits itself to quibbling with the language the Petition
`
`uses (as opposed to the substance of the arguments it made), or once again ignores
`
`the straightforward teachings of the art.
`
`I.
`
`Ground 1: The Petition Established that Baker and Bruckert Render
`the ’586 Patent’s Claims Obvious
`None of Patent Owner’s arguments distinguish Baker and Bruckert from
`
`the ’586 patent.
`
`Baker Teaches “Determining to Relay the Packet Based on a
`Comparison of the Identifiers”
`Patent Owner argues that Baker does not teach “determining to relay the
`
`packet based on a comparison of the identifiers.” (Response at 10.)
`
`-2-
`
`
`
`Patent Owner begins its response by noting that “[i]n almost all of Baker’s
`
`disclosures, Baker’s table does not include identifiers, and thus the” claimed
`
`“comparison” “cannot be made.” (Response at 2; see also id. at 13.) It does not
`
`matter that many of Baker’s embodiments operate this way; all that matters is that
`
`there are embodiments where a table of identifiers is used to make a packet
`
`forwarding determination. Obviousness is assessed by considering all that a
`
`reference teaches. See In re Mouttet, 686 F.3d 1322, 1332-33 (Fed. Cir. 2012).
`
`Patent Owner concedes that in at least some embodiments, Baker employs a
`
`lookup table that it uses to determine how to handle an incoming packet. (Response
`
`at 12.) But, Patent Owner argues that this is not what the claims require. According
`
`to Patent Owner, in the ’586 patent, “repeater units do not relay every received
`
`packet that is capable of being forwarded; they selectively relay only packets with
`
`ID code portions that match an entry in their table of identifiers.” (Id. at 10)
`
`“Baker’s lookup operation,” at least according to Patent Owner, “is only concerned
`
`with how to relay a packet, not determining to relay it in the first place.” (Id.) Thus,
`
`in Patent Owner’s view, Baker merely uses the lookup table to determine an
`
`outgoing channel for an incoming packet and then “always” relays the packet. (Id.
`
`at 12-15.) Accordingly, Patent Owner argues that the claimed “determining” does
`
`not occur because in Baker, it is “predetermined that the packet is always going to
`
`be relayed if possible.” (Id.)
`
`-3-
`
`
`
`This is not the extent of Baker’s teachings. As explained in the Petition (e.g.,
`
`Paper 1 at 45-46), Baker employs “local routing tables” stored on each of its network
`
`nodes. (Ex. 1004, ¶ [0030]; see also ¶¶ [0027]; [0031]; [0034].) The tables can store
`
`channel numbers or “a paired source-destination MAC address.” (Id., ¶ [0076].)
`
`Then, when a packet is received by a node, the node uses the channel number and/or
`
`address in the incoming packet to “look up an outgoing port and channel number in
`
`the locally stored connection table” for purposes of determine how to handle the
`
`packet. (Id., ¶¶ [0084]-[0085].)
`
`In arguing that this disclosure in Baker does not teach what the claims require,
`
`Patent Owner focuses on Baker’s statement that a packet “is always forwarded (if it
`
`can be)…” (Response at 13 (quoting Ex. 1004, ¶ [0030].) The operative language
`
`here is “if it can be.” Baker’s nodes do not “always” forward incoming packets.
`
`Instead, they do so only if they can. As Baker explains, nodes are only able to
`
`forward a packet if the channel/address information in the incoming packet matches
`
`an entry in the lookup table.
`
`This is exemplified in the below annotated version of Figure 13 from Baker.
`
`-4-
`
`
`
`(Id., Fig. 13 (annotated).) This figure shows the “procedure … implemented at a
`
`store and forward node … and at a packet destination node of the network.” (Id., ¶
`
`[0084].) When a packet is received (green step S1300), the node “reads the channel
`
`number” or “destination address” stored in the packet (yellow step S1302). (Id.)
`
`The node then proceeds to use the packet’s channel/address information to
`
`determine which of three possible courses of action to take. First, the “destination
`
`address may be employed … to determine whether the node is the final intended
`
`destination of the packet.” (Id.) If so, the node “depacketizes the data and passes”
`
`it along to the “intended recipient device” (option S1306). (Id.) Second, if the node
`
`-5-
`
`
`
`is “not the intended final destination,” Baker teaches that the “destination address”
`
`can be used “to look up an outgoing port and channel number in the locally stored
`
`connection table data for the node.” (Id., ¶ [0085].) Again, Baker teaches that this
`
`table can include “destination MAC address[es]” instead of or in addition to channel
`
`information to enable proper routing. (Id., ¶ [0076].) If “the table entry specifies a
`
`valid port and channel number the node … retransmits the packet … forwarding the
`
`packet along the next link in the chain” (blue option S1308). (Id.) Third, “[w]here
`
`no valid entry is found in the connection link table for the destination … the node
`
`sends a disconnect message” rather than relaying the packet (option S1304). (Id.)
`
`So, in sum, Baker teaches that its network nodes do in fact make a
`
`determination regarding whether to forward a packet by comparing identifying data
`
`in an incoming packet to data stored in a lookup table. If a match is found in the
`
`table, the packet is relayed (step S1308). If no match is found, the packet is not
`
`relayed and a disconnect message is sent (step S1304). This is exactly what the ’586
`
`patent’s “determining” limitation requires. Patent Owner completely ignores this
`
`operation and appears to assume that Baker will always, and in all cases, proceed to
`
`packet forward option S1308 and never proceed to option S1304. This does not
`
`establish non-obviousness. See Homeland Housewares, LLC v. Whirlpool Corp.,
`
`865 F.3d 1372, 1378 (Fed. Cir. 2017) (explaining that the Board must ignore and
`
`-6-
`
`
`
`should give no weight to arguments and testimony “that is plainly inconsistent with
`
`the record.”)
`
`When asked about the disclosure of Figure 13 at his deposition, Patent
`
`Owner’s expert Dr. Madisetti was unwilling to provide any explanation regarding
`
`how it is consistent with his opinions. (See, e.g., Ex. 1027, 14:10-23:7, 24:6-26:4.)
`
`Instead, he repeatedly evaded questions answering only that Baker’s text speaks for
`
`itself. (See id.) At one point, Dr. Madisetti stated that it “does not matter” if step
`
`S1308 is only performed if a match is found and not every time a packet is received.
`
`(See id., 24:19-25:12.) Dr. Madisetti appeared to take this position because Figure
`
`13, in his view, only entails the lookup of channel information in an incoming packet
`
`and not the claimed “identification code portion.” (See id.) But, as noted in the
`
`Petition, Baker also teaches that “paired MAC addresses” can be used in place of “a
`
`channel number.” (Ex. 1004, ¶¶ [0076], [0084]-[0085].) Further, Baker also
`
`explains that the lookup procedure in Figure 13 can employ “destination address”
`
`information in an incoming packet. (Id.) It is these combined teachings—which Dr.
`
`Madisetti apparently ignored—and not Figure 13 standing alone and in isolation that
`
`renders the claims obvious.
`
`Baker and Bruckert Teach a “Controller Operatively Coupled to
`… Reset Element”
`Patent Owner next argues that the combination of Baker and Bruckert does
`
`not teach a “controller operatively coupled to” a “reset element.” (Response at 15.)
`
`-7-
`
`
`
`Patent Owner does not dispute that the art teaches devices that include the claimed
`
`“reset element.” (Id.) Regardless, it argues that the Petition merely alleged that this
`
`“reset element” would have been “included” in the device of Baker and Bruckert,
`
`but not “operatively coupled” to a controller. (Id.)
`
`This makes little sense. Patent Owner has essentially taken position that
`
`Baker and Bruckert’s “reset element,” while present, could be floating, unconnected,
`
`and purposeless. This is not what the Petition argued, and it is not what the art
`
`teaches. The art makes clear that a “reset element” is connected so as to allow the
`
`entire device, including the device’s controller, to be reset.
`
`For instance, Baker teaches that each of its devices can be power cycled in
`
`their entirety. (Ex. 1004, ¶¶ [0024], [0061].) Patent Owner does not contest that this
`
`constitutes a “reset,” or that the structure that accomplishes the power cycle is a
`
`“reset element.” Similarly, Bruckert explains that reset elements operate to “set[]”
`
`a device’s “processor back to some predetermined or initial state.” (Ex. 1009, 35:21-
`
`23.) Thus, the reset element is not only present, but is connected to and impacts the
`
`operation of a device’s processor/controller.
`
`This is why the petition explained that a POSITA would understand Baker to
`
`include a “reset element” that “causes the device’s controller to reset its
`
`configuration.” (Petition at 37 (emphasis added).) This is also why the Petition
`
`explained that Bruckert teaches that “a controller can be reset in numerous ways.”
`
`-8-
`
`
`
`(Id. at 39 (emphasis added).) The petition did not merely allege that the prior art
`
`“includes” a reset element. It specifically explained how this reset element is
`
`connected to and functions to impact the operation of a device’s controller. Patent
`
`Owner has not explained how this is any different from what the ’586 patent requires.
`
`II. Ground 2: There Would Have Been a Strong and Straightforward
`Motivation to Combine McMillian with Baker and Bruckert
`Patent Owner next argues that the Petition’s reasons for combining the
`
`teachings of McMillian with Baker and Bruckert in Ground 2 are “untethered to any
`
`claim element.” (Response at 17.) This is not the case.
`
`The claims at issue in this ground—2-5, 7, 10-12, 16, 18, and 20—are
`
`thematically similar. They deal with methods for avoiding network issues like
`
`collisions, congestion, and interference; this is exactly what McMillian teaches. (See
`
`e.g., Petition at 52, 53.) Moreover, the motivation to combine identified in the
`
`petition is directly tied to the techniques for avoiding network issues taught by
`
`McMillian.
`
`As explained, McMillian teaches that network congestion and interference are
`
`a potential problem in networks where there are many transmitters. (See id. at 57
`
`(citing Ex. 1018, 16:45-49.) The Petition goes on to note that a POSITA would
`
`understand the system of Baker and Bruckert to be subject to these problems. (See
`
`id.) And, the Petition then stated that a POSITA would understand that use of
`
`McMillian’s collision avoidance and network congestion reducing techniques—
`
`-9-
`
`
`
`including listening for interference, delaying transmission, and the like as required
`
`by the ’586 patent’s claims—would address these problems and improve Baker and
`
`Bruckert. (See id.)
`
`Patent Owner does not substantively address any of this. It does not challenge
`
`that McMillian teaches what these claims require. Nor does it point to any reasons
`
`why McMillian’s collision avoidance and other techniques could not be successfully
`
`applied to improve Baker and Bruckert. Instead, Patent Owner does little more than
`
`discuss the length of the motivation to combine section. But, “[t]he amount of
`
`explanation needed to” show a motivation to combine “necessarily depends on
`
`context. A brief explanation may do all that is needed if … the technology is simple
`
`and familiar and the prior art is clear….” Personal Web Tech., LLC v. Apple, Inc.,
`
`848 F.3d 987, 994 (Fed. Cir. 2017). This is the case here: the ’586 patent claims
`
`well-known, and routinely used techniques for improving network communication.
`
`And, McMillian admittedly teaches those very same techniques and explains that
`
`networks (like those of Baker and Bruckert) can be improved by using them.
`
`III. Ground 3: The Petition Also Established that Marman and Shoemake
`Render the Claims Obvious
`Patent Owner has also failed to distinguish Marman and Shoemake from
`
`the ’586 patent.
`
`-10-
`
`
`
`A POSITA Would Have Understood Marman Itself Teaches the
`Claimed Packets
`Patent Owner begins by taking issue with Marman’s teaching of the claimed
`
`“communication packet.”
`
`Putting aside the teachings of Shoemake, as explained in the Petition, a
`
`POSITA would have understood Marman to itself teach and employ such a packet.
`
`(Petition at 61-64.) Marman explains that its system uses packet-based
`
`communications. (Ex. 1006, 37:28-38:12, 40:2-7.) Moreover, Marman references
`
`packets with data, preambles, and addresses, and explains that its packets are
`
`structured such that they allow for proper synchronization, routing, and error
`
`correction. (Id., 38:9-12, 39:11-15, 40:3-7, 40:20-21, 40:26-28, 44:15-17.)
`
`Patent Owner responds by characterizing Marman as teaching only “disparate
`
`pieces of transmitted information” that are not part of a “single data structure.”
`
`(Response at 20.) But, it only arrives at this erroneous conclusion by reading
`
`Marman completely in isolation and without the benefit of the background
`
`knowledge possessed by a POSITA. This is not how prior art is assessed. When
`
`considered in the proper context, the portions of Marman Patent Owner cites only
`
`serve to further confirm that Marman teaches the very type of packet the claims
`
`here require.
`
`As Patent Owner itself repeatedly points out (id. at 22, 23, 24, 25), Marman’s
`
`system employs “media access layer and logical link layer protocols” and other
`
`-11-
`
`
`
`protocols when transmitting messages between sensors and its base station. (Ex.
`
`1006, 37:28-38:3, 44:15-17.) Patent Owner concludes that this means that Marman
`
`employs a distinct “data message” (id. at 24), “link layer packet” (id. at 22-23), and
`
`“some” other unspecified packets (id. at 23) that bear no relation to each other. This
`
`is not an accurate characterization of how a POSITA would have understood
`
`Marman.
`
`The “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. (See Ex. 1019, p. 5 (noting that the “802.2 Logical
`
`Link Control” and “802.11 medium access” standards are part of the IEEE 802
`
`“family of standards for … networks”). The 802 family of network standards are an
`
`implementation of the “Open Systems Interconnection (OSI)” network model. (Id.)
`
`In this model, network communication is facilitated by a series of layers—
`
`implemented in hardware and software—that operate in concert to package or
`
`encapsulate data messages for transmission over a network. (See Ex. 1023, pp. 15-
`
`16.) As Patent Owner’s expert himself explains, “a POSITA would have been aware
`
`of” the OSI model and these “conceptual layers.” (Ex. 2006, ¶ 63; see also Ex. 1027,
`
`36:8-37:2 (recognizing that the OSI model and its layers were known to a POSITA).)
`
`An example of these layers are shown in the below figure from the IEEE 802
`
`standard:
`
`-12-
`
`
`
`(Id., p. 16.) As can be seen, the “logical link control” (or LLC) and “medium access”
`
`(or MAC) layers referenced in Marman make up the “data link” layer of the IEEE
`
`802 standard. (Id.; see also Ex. 1019, p. 5.) These are not “disparate,” unrelated
`
`network communication layers. Instead, they are part of one unified protocol or
`
`architecture with multiple layers that operate together to allow for network
`
`communication. (See Ex. 1028, ¶¶ 17-32.)
`
`The MAC and LLC layers discussed in Marman are not only part of the
`
`standard, but are also repeatedly discussed in the patent literature. For example,
`
`prior to ’586 patent’s filing it was well-known (and a POSITA would have
`
`recognized) that “[m]odern communication network architectures are typically
`
`-13-
`
`
`
`organized as a series of hardware and software levels or ‘layers’ within each”
`
`communicating device. (Ex. 1025, 1:61-63; see also Ex. 1028, ¶¶ 33-44.) “These
`
`layers interact to format data for transfer between, e.g., a source station and a
`
`destination station communicating over the network.” (Ex. 1025, 1:63-65.) Each
`
`layer performs “predetermined services … on the data as it passes through” the layer,
`
`“and the layers communicate with each other by means of the predefined protocols.”
`
`(Id. 1:66-2:1.) “The lower layers … are generally standardized and are typically
`
`implemented in hardware and firmware, whereas the higher layers are generally
`
`implemented in the form of software running on the stations….” (Id., 2:2-6.)
`
`The patent literature depicts this layered architecture in the same way as the
`
`IEEE 802 standard itself does. It also unambiguously explains how the layers work
`
`together to communicate data:
`
`-14-
`
`
`
`(Id., Fig. 1.) As shown, data transmission starts when “sending process 104
`
`executing on the source station 110” “generat[es] data.” (Id., 3:17-19.) This same
`
`data is then “pass[ed] … to the application layer 112 and down through the layers of
`
`the protocol stack” where it is “sequentially formatted as a frame” (or “packet”) “for
`
`delivery onto the channel 180 as bits. … Data flow is schematically illustrated by
`
`solid arrows.” (Id., 1:52-55, 3:17-26.) The “Logical Link Control (LLC 122)” and
`
`“Media Access Control (MAC 124)” are simply sublayers within the “data link”
`
`layer. (Id., 2:32-40; see also Ex. 1023, p. 16; Ex. 1019, p. 5.) The LLC layer
`
`contributes to the overall process by facilitating exchange of “information frames”
`
`over “logical link[s]” and allows for “error recovery procedures.” (Ex. 1023, p. 19.)
`
`The “MAC sublayer performs the addressing and recognition of frames in support
`
`of LLC.” (Id.; see also Ex. 1026, 14:61-17:2 (explaining the interrelated functions
`
`and additive nature of the different layers of the “OSI model”); Fig. 9.)
`
`Given this, a POSITA reading Marman would not have considered it to be
`
`teaching transmission of “disparate” and unrelated pieces of information. (See Ex.
`
`1028, ¶¶ 45-50.) Instead, as noted in the Petition (e.g., Petition at 61-62), a POSITA
`
`would have immediately recognized that Marman actually teaches standard IEEE
`
`802 packets. (See id.) These packets would have been understood to have been
`
`generated using well-known, standardized network protocols with interrelated layers
`
`-15-
`
`
`
`implemented in hardware and software on each networked device that operate on the
`
`same data message as it is packetized and then transmitted over a network.
`
`More particularly, in Marman, software running on each device generates a
`
`“data message.” (Ex. 1006, 40:26-28.) This is the data for transmission generated
`
`by the higher application layer in the network communication protocol stack. Per
`
`Marman, these messages are packetized (id., 37:28-38:12, 40:2-7), have addresses
`
`and other information added to facilitate routing, and then pass through and are
`
`conformed to various standardized network protocols including the lower media
`
`access control and logical link control protocol layers (id., 38:9-12, 39:11-15, 40:3-
`
`7, 40:20-21, 44:15-17). All of this would have been (and can only be) understood
`
`to be part of one interrelated network communication protocol. Thus, rather than
`
`completely unrelated “data messages,” “logical link layer packets,” and other
`
`unspecified packets, a POSITA would have understood Marman to use exactly the
`
`same type of packets generated by the same type of layered protocol stack discussed
`
`above. The data message generated by Marman’s application layer passes through
`
`its protocol stack—including the MAC and LLC layers—is packetized, and then
`
`transmitted. (See Ex. 1028, ¶¶ 46-48.) It unambiguously follows that the data,
`
`preamble, address, and other packet portions referenced in Marman are in fact
`
`related: they are part of a single packet created as data passes through the layers of
`
`Marman’s standard-based protocol stack. (See id., ¶ 49.)
`
`-16-
`
`
`
`Patent Owner’s arguments to the contrary ignore what a POSITA would have
`
`known regarding these well-known network communication protocols. Patent
`
`Owner instead approaches 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.
`
`For instance, Patent Owner states that “[j]ust because Marman discloses
`
`logical link layer packets in one section, this does not mean that all other portions of
`
`numerous other messages disclosed in Marman are also sent together or as part of
`
`the logical link layer packets.” (Response at 22.) Similarly, Patent Owner posits
`
`that “[t]he fact that one layer uses a packet structure does not imply that all others
`
`do too.” (Response at 22.) There is no such thing as a standalone “logical link layer
`
`packet.” The logical link control layer is part of an overall, known layered network
`
`protocol. It works with the other layers to perform the functions needed for network
`
`communication. Rather than being an isolated layer with its own packets, this layer
`
`operates on and adds to packets as they progress through the protocol layers. A
`
`packet passing through the LLC layer thus includes the same components as that
`
`received from the layers above the LLC layer in the stack. (See, e.g., Ex. 1025, 3:17-
`
`26; Fig. 1; see also Ex. 1026, 16:23-17:2; Figs. 9-10; Ex. 1028, ¶¶ 43-44.) So,
`
`Marman’s reference to a “logical link layer” that operates on packets does in fact
`
`mean that all of Marman’s other protocol layers also contribute to data packetization.
`
`-17-
`
`
`
`Indeed, the LLC layer and these other layers contribute to the packetization of the
`
`same data because this is how layered network protocols work.
`
`Patent Owner even appears to completely misunderstand what a packet is. For
`
`example, Patent Owner takes issue with the Petition’s explanation that Marman’s
`
`“packet also constitutes part of a ‘data message.’” (Response at 24.) According to
`
`Patent Owner, “the claims require the inverse—that the data portion constitutes part
`
`of the packet.” (Id.) But the process of packetizing a data message entails chopping
`
`it up into smaller pieces for transmission (i.e., the packets). (Ex. 1003, ¶ 47.) The
`
`packets are then reassembled back into a complete message upon arrival at their
`
`destination. (Id., ¶ 48.) This is why in ’586 patent’s claims, the “communication
`
`packet” includes only a “data portion.” The packet does not and is not required to
`
`include an entire data message as Patent Owner presumes.
`
`Patent Owner also nonsensically argues that a POSITA would not have
`
`recognized Marman to be teaching standardized packets—like that referenced in
`
`Shoemake—“because Marman never mentions or even alludes to Shoemake or the
`
`‘802.11 wireless packet’….” (Response at 25.) But, Marman’s system already
`
`employs network protocol layers present in the IEEE 802 standard, including the
`
`MAC and LLC sublayers. (Ex. 1006, 37:28-38:14.) Marman does far more than
`
`“allude” to use of 802.11 wireless packet; it employs standard network protocols that
`
`are designed to generate, operate on, and use such packets.
`
`-18-
`
`
`
`Patent Owner attempts to bolster these erroneous points with a declaration
`
`signed by its expert Dr. Madisetti. But, Dr. Madisetti simply repeats—almost
`
`verbatim with no elaboration or further explanation—the same faulty arguments.
`
`(See Ex. 2006, ¶¶ 60-70.) “Conclusory assertions” in a brief that are “merely
`
`repeated in conclusory and unsupported statements by an expert witness in support,
`
`are not persuasive….” Coalition for Affordable Drugs VII LLC v. Pozen Inc., Case
`
`IPR2015-01680, Paper 18 at 15 (Feb. 11, 2016); see also 37 CFR 42.65(a).
`
`Marman and Shoemake Teach Packets with the Claimed
`“Integrity Portion”
`Patent Owner next argues that Marman does not teach a “communication
`
`packet” with an “integrity portion.” (Response at 26.) While it recognizes that
`
`Marman employs “error control” (which admittedly embraces “many different
`
`ways” of checking for and controlling errors), it goes on to argue that ’586 patent’s
`
`claims require an “integrity portion” like a “checksum” that is “used to verify that
`
`the data within a packet does not have any errors introduced.” (Id. at 27.) According
`
`-19-
`
`
`
`to Patent Owner, “error control” in Marman may be performed without “checking
`
`the integrity of the packet data.”1 (Id. at 27.)
`
`Patent Owner ignores that Marman does not just refer to “error control” in
`
`abstract. Instead, in Marman “error control” is performed by “media access layer
`
`and logical link layer protocols.” (Ex. 1006, 38:4-14.) As explained in the IEEE
`
`802 standard, the media access control layer employs an “IEEE 32-bit cyclic
`
`redundancy code (CRC)” in each packet. (Ex. 1019, p. 50.) This CRC code is
`
`referred to as a “frame check sequence” because it allows the standardized protocol
`
`layers to confirm the integrity of a received frame or packet. (Ex. 1019, p. 213.) As
`
`explained in the standard, the “MAC … detect[s] a satisfactory FCS” by engaging
`
`in comparison calculations to determine if packet contains any errors. (Id., p. 77.)
`
`Because it employs standardized protocols, Marman does not teach just generic,
`
`unspecified “error control.” Instead, given Marman’s use of standardized MAC and
`
`LLC protocol layers, a POSITA would have understood it to teach packets with an
`
`“integrity portion” no different from the “checksum” in ’586 patent.
`
`1 Patent Owner does not propose a claim construction for “integrity portion” here
`
`(nor did it in district court). Yet, its arguments improperly seek to limit the term to
`
`just the embodiment in the specification.
`
`-20-
`
`
`
`Next, Patent Owner makes much of the fact that during prosecution of the ’586
`
`patent, the Examiner stated that “Marman fail[s] to disclose [a] message include[ing]
`
`a checksum.” (E.g., Ex. 1012, p. 101.) Marman does not use the word “checksum.”
`
`But, the claims here are not limited to just packets with a “checksum.” They embrace
`
`any “integrity portion.” Moreover, Marman teaches what the claims require when
`
`considered in view of the knowledge of a POSITA. The Examiner—unlike the
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
